Date:   Tue, 9 Aug 2022 18:51:59 +0300
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Paul Cercueil <paul@...pouillou.net>, linux-kernel@...r.kernel.org,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        linux-samsung-soc@...r.kernel.org, Lee Jones <lee@...nel.org>
Subject: Re: [PATCH 13/28] mfd: sec: Remove #ifdef guards for PM related
 functions

On 09/08/2022 18:33, Lee Jones wrote:
> On Mon, 08 Aug 2022, Krzysztof Kozlowski wrote:
> 
>> On 07/08/2022 17:52, Paul Cercueil wrote:
>>> Use the new DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros
>>> to handle the .suspend/.resume callbacks.
>>>
>>> These macros allow the suspend and resume functions to be automatically
>>> dropped by the compiler when CONFIG_SUSPEND is disabled, without having
>>> to use #ifdef guards.
>>>
>>> The advantage is then that these functions are now always compiled
>>> independently of any Kconfig option, and thanks to that bugs and
>>> regressions are easier to catch.
>>>
>>> Signed-off-by: Paul Cercueil <paul@...pouillou.net>
>>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
>>
>> The address does not work. Please don't add it to commit log.
>>
>>> Cc: linux-samsung-soc@...r.kernel.org
>>
>> This is also not really needed in commit log... it's just a mailing list...
>>
>> I actually never understood why people want to add to commit log, so to
>> something which will last 10 years, Cc-ing other folks, instead of
>> adding such tags after '---'. Imagine 10 years from now:
>>
>> 1. What's the point to be cced on this patch after 10 years instead of
>> using maintainers file (the one in 10 years)? Why Cc-ing me in 10 years?
>> If I am a maintainer of this driver in that time, I will be C-ced based
>> on maintainers file. If I am not a maintainer in 10 years, why the heck
>> cc-ing me based on some 10-year old commit? Just because I was a
>> maintainer once, like 10 years ago?
> 
> Why would that happen?
> 
> These tags are only used during initial submission.

No, the tags are used in any other resends, backports etc while
traveling through different trees. I think only stable-backports do not
use them, but all other gfp+git-send will follow the tags.

> 
>> 2. Or why cc-ing such people when backporting to stable?
> 
> That doesn't happen either.

Indeed, stable does not use these Cc.

> 
>> It's quite a lot of unnecessary emails which many of us won't actually
>> handle later...
>>
>> I sincerely admit I was once also adding such Cc-tags. But that time my
>> employer was counting lines-of-patch (including commit log)... crazy, right?
> 
> Nothing wrong with adding these tags IMHO.  It's what they're for.
> 
> I use them when I'm maintaining a large amount of out-of-tree, but
> to-be-upstreamed patches over several versions.  Re-applying the
> recipients list can become pretty labour-some after several
> iterations.

You can do it still while keeping the tags after ---. Only patch-related
workflows strip such tags. If you cherry-pick, rebase, merge, you always
get the content of ---.

The same as typical changelog (not cover letter but one in the patch) -
you keep it after --- and it does not disappear.

> 
> Adding them under the '---' doesn't work when the purpose of them is
> to keep the recipients list in Git history.

This I understand, what I did not understand (and you did not explain)
is what would be the purpose to keep them in Git history. What is the
point to have them in commit log of 10 year old commit?

Best regards,
Krzysztof

Powered by blists - more mailing lists