lkml.org 
[lkml]   [2022]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 13/28] mfd: sec: Remove #ifdef guards for PM related functions
From
On 08/08/2022 12:28, Paul Cercueil wrote:
> Hi Krzysztof,
>
> Le lun., août 8 2022 at 12:11:02 +0300, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> a écrit :
>> 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@crapouillou.net>
>>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>
>> The address does not work. Please don't add it to commit log.
>
> That's what get-maintainers gave me, and I didn't get any error sending
> at that address.

I know, I was bugging Bartlomiej and other Samsung folks to fix it and
we reached some kind of conclusion but it never resulted in a patch.

> But I'll take your word.
>
>>> Cc: linux-samsung-soc@vger.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?
>>
>> 2. Or why cc-ing such people when backporting to stable?
>>
>> 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?
>
> Yeah, well, I can add these tags after the '---' line. Nobody ever told
> me that I was doing it wrong, and I see Cc: tags quite often in commit
> messages, so I thought it was common practice.

It indeed is a practice, which I do not understand. :) My complaining
about it was just complaining, not as a feedback required to change.

>
>>> ---
>>> drivers/mfd/sec-core.c | 7 +++----
>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
>>> index 1fb29c45f5cf..a467de2b2fea 100644
>>> --- a/drivers/mfd/sec-core.c
>>> +++ b/drivers/mfd/sec-core.c
>>> @@ -455,7 +455,6 @@ static void sec_pmic_shutdown(struct i2c_client
>>> *i2c)
>>> regmap_update_bits(sec_pmic->regmap_pmic, reg, mask, 0);
>>> }
>>>
>>> -#ifdef CONFIG_PM_SLEEP
>>> static int sec_pmic_suspend(struct device *dev)
>>
>> Did you test W=1 with !CONFIG_PM_SLEEP? No warnings?
>
> I tested the PR with !CONFIG_PM_SLEEP, correct. sec-core.o compiles
> fine. No warnings with W=1.

Ah, I see now. _DEFINE_DEV_PM_OPS uses __maybe_unused for such case.

Looks fine then. With dropped Bartlomiej Cc:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>


Best regards,
Krzysztof

\
 
 \ /
  Last update: 2022-08-08 12:06    [W:0.106 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site