Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a625a1b4-6ecd-79d9-3d13-f42fd5b8275c@linaro.org>
Date:   Mon, 8 Aug 2022 12:11:02 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: [PATCH 13/28] mfd: sec: Remove #ifdef guards for PM related
 functions
Content-Language: en-US
To:     Paul Cercueil <paul@crapouillou.net>,
        Lee Jones <lee.jones@linaro.org>
Cc:     linux-kernel@vger.kernel.org,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
        linux-samsung-soc@vger.kernel.org
References: <20220807145247.46107-1-paul@crapouillou.net>
 <20220807145247.46107-14-paul@crapouillou.net>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <20220807145247.46107-14-paul@crapouillou.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

> 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?


> ---
>  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?


Best regards,
Krzysztof