[PATCH v2 3/3] trace: Fix alignment logic in flyrecord header

[Tom Rini]

On Mon, Sep 25, 2023 at 04:10:38PM +0200, Michal Simek wrote:
> Hi Simon,
> 
> On 9/25/23 16:01, Simon Glass wrote:
> > Hi Michal,
> > 
> > On Mon, 25 Sept 2023 at 07:38, Michal Simek <michal.simek at amd.com> wrote:
> > > 
> > > 
> > > 
> > > On 9/25/23 15:10, Simon Glass wrote:
> > > > Hi Michal,
> > > > 
> > > > On Mon, 25 Sept 2023 at 00:06, Michal Simek <michal.simek at amd.com> wrote:
> > > > > 
> > > > > Hi Simon,
> > > > > 
> > > > > 
> > > > > On 9/23/23 20:13, Simon Glass wrote:
> > > > > > Current alignment which is using 16 bytes is not correct in connection to
> > > > > > trace_clocks description and it's length.
> > > > > > That's why use start_addr variable and record proper size based on used
> > > > > > entries.
> > > > > > 
> > > > > > Fixes: be16fc81b2ed ("trace: Update proftool to use new binary format").
> > > > > > Signed-off-by: Michal Simek <michal.simek at amd.com>
> > > > > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > > > > > ---
> > > > > > 
> > > > > > Changes in v2:
> > > > > > - s/start_addr/start_ofs/g'
> > > > > > 
> > > > > >     tools/proftool.c | 31 +++++++++++++++++++++++++++++--
> > > > > >     1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > Applied to u-boot-dm, thanks!
> > > > > 
> > > > > FYI: I have merged it to my tree and already sent pull request to Tom.
> > > > > Without it I couldn't pass CI loop to get all reviewed features in.
> > > > > 
> > > > > https://lore.kernel.org/all/ab72c480-e9f8-416e-adf5-726f7d40c4f5@amd.com/
> > > > 
> > > > Ah OK, well that's fine. It was in my patchwork queue still, which
> > > > suggests that the patches were not set to 'applied'?
> > > 
> > > I am not using patchwork. But I expect my reply to cover letter was recorded there.
> > 
> > Probably. If you reply to each patch, it shows up in the patch, but
> > the cover letter is hidden somewhere else.
> 
> I have never started to like patchwork. I installed that client long time
> ago, I also have account for quite a long time.
> 
> > If you are not using patchwork, how come you are a custodian? Is
> > someone else dealing with patchwork for you?
> 
> Not really. I am just keep track on it via emails.
> 
> DT folks did wire CI loop on every patch which they get. I am not aware
> about any feature like this which would bring me something. That's why I am
> considering patchwork as unneeded layer. And I also don't think that I have
> read anywhere that all custodians should be using patchwork.

Right, patchwork isn't required, but can be helpful.  Part of how
patchwork is maintained for everyone (in U-Boot) is that I have a script
that will update the status of patches to accepted and add the githash,
based on the "patchwork hash" of a given commit.  There's a number of
automated tooling things that other projects use which could be helpful
here, but due to lack of time/resources, we haven't tried them here.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230925/612238a4/attachment.sig>