[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8a0662b7-2801-47a2-9c91-4eb0e7ef307b@linaro.org>
Date: Fri, 25 Jul 2025 15:15:37 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
linux-tip-commits@...r.kernel.org, Donghoon Yu <hoony.yu@...sung.com>,
Youngmin Nam <youngmin.nam@...sung.com>, John Stultz <jstultz@...gle.com>,
Will McVicker <willmcvicker@...gle.com>, x86@...nel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Arnd Bergmann <arnd@...nel.org>
Subject: Re: [tip: timers/clocksource] clocksource/drivers/exynos_mct: Don't
register as a sched_clock on arm64
On 25/07/2025 12:34, Ingo Molnar wrote:
>
> * Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
[ ... ]
>>> 3)
>>>
>>> There's also a stray Tested-by tag by one of the SOB entries:
>>>
>>>> Signed-off-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>> Reviewed-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>> Tested-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>
>>> When someone passes along a patch, it's implicit that they not only
>>> have reviewed the patch, but have also tested it to a certain extent
>>
>> In this specific case where the original commit is from AOSP, this chain
>> seems to make sense. Souns like:
>>
>> "I was in the original commit delivery path"
>> "I reviewed this patch carried to Linux"
>> "I tested it on Linux"
>
> Yeah, so then this should be documented by adding a comment to the tag
> itself:
>
> Signed-off-by: Donghoon Yu <hoony.yu@...sung.com>
> Signed-off-by: Youngmin Nam <youngmin.nam@...sung.com>
> Signed-off-by: Will McVicker <willmcvicker@...gle.com>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
> Tested-by: Youngmin Nam <youngmin.nam@...sung.com> # AOSP -> Linux port
> Reviewed-by: Youngmin Nam <youngmin.nam@...sung.com> # AOSP -> Linux port
>
> Otherwise it's just confusing as to why there's duplicate SOB and
> Reviewed-by entries.
Yes, I agree it is more clear.
> But as long as the porting was basically just a cherry-pick, these
> extra tags are probably superfluous. If there was a conflict resolved
> by one of the maintainers along the SOB chain, that should be marked
> explicitly, which I see was already done in some cases:
>
> [ dlezcano : Fixed conflict with 20250614175556.922159-2-linux@...ck-us.net ]
Ok, noted for the next time.
>>> 4)
>>>
>>> Why is the 'Link' tag just in the middle of the SOB chain, instead at the end of it?
>>
>> I don't know. Link must be at the end It is stated somewhere in the
>> documentation?
>>
>> I use git b4 -s <msg-id> and the tool adds the Link then my sign off.
>
> Yeah, so using tools and not looking at the end result will often just
> create a random tag order that looks messy.
>
> On preferred tag ordering, see:
>
> Documentation/process/maintainer-tip.rst
>
> Ordering of commit tags
> ^^^^^^^^^^^^^^^^^^^^^^^
> ...
>
> 'Link' is at the end of the list of tags.
>
> There's some logic to the -tip tag ordering (more important tags go
> before less important tags), but it's mostly just an arbitrary order
> that we try to stick to within -tip.
Thanks for the pointer !
>>> Presumably this is the proper SOB chain:
>>>
>>>> Author: Donghoon Yu <hoony.yu@...sung.com>
>>>
>>>> Signed-off-by: Donghoon Yu <hoony.yu@...sung.com>
>>>> Signed-off-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>> Signed-off-by: Will McVicker <willmcvicker@...gle.com>
>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>>>> Acked-by: John Stultz <jstultz@...gle.com>
>>>> Link: https://lore.kernel.org/r/20250620181719.1399856-3-willmcvicker@google.com
>>>
>>> Correct?
>>
>>
>
> So I got no answer for this question, but I suppose my assumption is
> correct - so I've rebased the tip:timers/clocksource commits to fix the
> misattribution and a number of other problems, and also fixed various
> typos, spelling mistakes and inconsistencies in the changelogs while at
> it. Let me know if I got something wrong.
If the rebase is possible, I suggest to take the opportunity to remove
the following patches:
commit 5d86e479193b - clocksource/drivers/exynos_mct: Add module support
commit 7e477e9c4eb4 - clocksource/drivers/exynos_mct: Fix section
mismatch from the module conversion
Because of:
[1]
https://lore.kernel.org/all/20250725090349.87730-2-krzysztof.kozlowski@linaro.org/
[2]
https://lore.kernel.org/all/bccb77b9-7cdc-4965-aa05-05836466f81f@app.fastmail.com/
> I've attached a delta-patch of the changelog changes below - note that
> I skipped the commit IDs to make the diff easier to read.
I have one question regarding the 'handler', when there is a message like:
[ handler: I did some changes ]
...
Signed-off-by: John Doe <handler@...nel.org>
Does the 'handler' have to match the email name ?
For example below, there is:
[ dlezcano : Fixed conflict with
20250614175556.922159-2-linux@...ck-us.net ]
Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
Is this form ok, or should it be:
[ daniel.lezcano: Fixed conflict with
20250614175556.922159-2-linux@...ck-us.net ]
?
> ===================>
> --- 2025-07-25 12:15:26.024284067 +0200
> +++ 2025-07-25 12:15:18.761435799 +0200
> @@ -10,6 +10,7 @@ Date: Tue Jul 15 14:18:33 2025 +0200
> the module loading.
>
> Fix this by adding the __init_or_module annotation for the functions:
> +
If my understanding of the documentation is correct, it seems to me the
delta is ok. Until now, I was relying on the tool to put the different
tags in the correct order, I thought it was in the arrival order.
Thanks for fixing this. Is there an existing script checking the tags
order is correct regarding the tip criteria ?
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists