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

Michal Simek michal.simek at amd.com
Mon Sep 25 16:21:17 CEST 2023



On 9/25/23 16:19, Tom Rini wrote:
> 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.

Can you share that script? I am happy to run it and pretty much close my list.
I am using b4 for applying patches that's why all message-ids are listed in the 
history which will uniquely identify that patches.

Thanks,
Michal



More information about the U-Boot mailing list