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;
Date:   Tue, 9 Aug 2022 16:33:52 +0100
From:   Lee Jones <lee.jones@linaro.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Paul Cercueil <paul@crapouillou.net>, linux-kernel@vger.kernel.org,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
        linux-samsung-soc@vger.kernel.org, Lee Jones <lee@kernel.org>
Subject: Re: [PATCH 13/28] mfd: sec: Remove #ifdef guards for PM related
 functions
Message-ID: <YvJ+YPAynhFKj5DR@google.com>
References: <20220807145247.46107-1-paul@crapouillou.net>
 <20220807145247.46107-14-paul@crapouillou.net>
 <a625a1b4-6ecd-79d9-3d13-f42fd5b8275c@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a625a1b4-6ecd-79d9-3d13-f42fd5b8275c@linaro.org>
Precedence: bulk

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

Why would that happen?

These tags are only used during initial submission.

> 2. Or why cc-ing such people when backporting to stable?

That doesn't happen either.

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

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

-- 
DEPRECATED: Please use lee@kernel.org