All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Richard Fitzgerald <rf@opensource.cirrus.com>
Cc: Paul Cercueil <paul@crapouillou.net>,
	linux-kernel@vger.kernel.org, patches@opensource.cirrus.com,
	Lee Jones <lee@kernel.org>
Subject: Re: [PATCH 20/28] mfd: arizona: Remove #ifdef guards for PM related functions
Date: Mon, 8 Aug 2022 15:47:03 +0100	[thread overview]
Message-ID: <YvEh53o4I3Q6+zho@google.com> (raw)
In-Reply-To: <a27df713-31e6-a0d5-7004-80f3f7d952e6@opensource.cirrus.com>

On Mon, 08 Aug 2022, Richard Fitzgerald wrote:

> On 08/08/2022 12:01, Paul Cercueil wrote:
> > 
> > 
> > Le lun., août 8 2022 at 11:43:31 +0100, Richard Fitzgerald
> > <rf@opensource.cirrus.com> a écrit :
> > > On 08/08/2022 11:06, Paul Cercueil wrote:
> > > > Hi Richard,
> > > > 
> > > > Le lun., août 8 2022 at 10:53:54 +0100, Richard Fitzgerald
> > > > \x7f<rf@opensource.cirrus.com> a écrit :
> > > > > On 07/08/2022 15:52, Paul Cercueil wrote:
> > > > > > Only export the arizona_pm_ops if CONFIG_PM is set, but leave the
> > > > > > suspend/resume functions (and related code) outside #ifdef guards.
> > > > > > 
> > > > > > If CONFIG_PM is not set, the arizona_pm_ops will be defined as
> > > > > > "static __maybe_unused", and the structure plus all the callbacks will
> > > > > > be automatically dropped by the compiler.
> > > > > > 
> > > > > > 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: patches@opensource.cirrus.com
> > > > > > ---
> > > > > >   drivers/mfd/arizona-core.c | 21 +++++++++++----------
> > > > > >   drivers/mfd/arizona-i2c.c  |  2 +-
> > > > > >   drivers/mfd/arizona-spi.c  |  2 +-
> > > > > >   3 files changed, 13 insertions(+), 12 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> > > > > > index cbf1dd90b70d..c1acc9521f83 100644
> > > > > > --- a/drivers/mfd/arizona-core.c
> > > > > > +++ b/drivers/mfd/arizona-core.c
> > > > > > @@ -480,7 +480,6 @@ static int
> > > > > > wm5102_clear_write_sequencer(struct \x7f\x7f\x7farizona *arizona)
> > > > > >       return 0;
> > > > > >   }
> > > > > >   \x7f-#ifdef CONFIG_PM
> > > > > >   static int arizona_isolate_dcvdd(struct arizona *arizona)
> > > > > 
> > > > > __maybe_unused?
> > > > 
> > > > No need. The symbols are always referenced.
> > > > 
> > > > > >   {
> > > > > >       int ret;
> > > > > > @@ -742,9 +741,7 @@ static int
> > > > > > arizona_runtime_suspend(struct device \x7f\x7f\x7f*dev)
> > > > > 
> > > > > __maybe_unused?
> > > > > 
> > > > > >   \x7f      return 0;
> > > > > >   }
> > > > > > -#endif
> > > > > >   \x7f-#ifdef CONFIG_PM_SLEEP
> > > > > >   static int arizona_suspend(struct device *dev)
> > > > > 
> > > > > __maybe_unused?
> > > > > 
> > > > > >   {
> > > > > >       struct arizona *arizona = dev_get_drvdata(dev);
> > > > > > @@ -784,17 +781,21 @@ static int arizona_resume(struct device *dev)
> > > > > 
> > > > > __maybe_unused?
> > > > > 
> > > > > >   \x7f      return 0;
> > > > > >   }
> > > > > > -#endif
> > > > > >   \x7f+#ifndef CONFIG_PM
> > > > > > +static __maybe_unused
> > > > > > +#endif
> > > > > 
> > > > > No need to ifdef a __maybe_unused.
> > > > 
> > > > Yes, it is needed, because the symbol is conditionally exported. If
> > > 
> > > Why conditionally export it?
> > > 
> > > > !CONFIG_PM, we want the compiler to discard the dev_pm_ops
> > >  and all the
> > > > callbacks, hence the "static __maybe_unused". That's the same
> > > > trick used > in _EXPORT_DEV_PM_OPS().
> > > > 
> > > > (note that this patch is broken as it does not change the struct
> > > > name, \x7fin the !PM case, which causes conflicts with the .h. I'll
> > > > fix in v2)
> > > > 
> > > > > >   const struct dev_pm_ops arizona_pm_ops = {
> > > > > > -    SET_RUNTIME_PM_OPS(arizona_runtime_suspend,
> > > > > > -               arizona_runtime_resume,
> > > > > > -               NULL)
> > > > > > -    SET_SYSTEM_SLEEP_PM_OPS(arizona_suspend, arizona_resume)
> > > > > > -    SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(arizona_suspend_noirq,
> > > > > > -                      arizona_resume_noirq)
> > > > > > +    RUNTIME_PM_OPS(arizona_runtime_suspend,
> > > > > > +               arizona_runtime_resume,
> > > > > > +               NULL)
> > > > > > +    SYSTEM_SLEEP_PM_OPS(arizona_suspend, arizona_resume)
> > > > > > +    NOIRQ_SYSTEM_SLEEP_PM_OPS(arizona_suspend_noirq,
> > > > > > +                  arizona_resume_noirq)
> > > > > >   };
> > > > > > +#ifdef CONFIG_PM
> > > > > >   EXPORT_SYMBOL_GPL(arizona_pm_ops);
> > > > > > +#endif
> > > > > 
> > > > > This ifdeffing is ugly. Why must the structure only be exported if
> > > > > CONFIG_PM is set?
> > > > 
> > > > So that all the PM code is garbage-collected by the compiler if
> > > > !CONFIG_PM.
> > > 
> > > The functions will be dropped if they are not referenced. That doesn't
> > > answer why the struct must not be exported.
> > > 
> > > What is the aim of omitting the struct export?
> > 
> > The functions are always referenced by the dev_pm_ops structure.
> > Omitting the struct export means that the struct can now be a "static
> > __maybe_unused" symbol in the !CONFIG_PM case, and everything related to
> > PM will be automatically removed by the compiler.
> > 
> > Otherwise, the symbol is exported as usual. The symbol being
> > conditionally exported is not a problem - the struct is always
> > referenced (as it should be) using the pm_sleep_ptr() or pm_ptr()
> > macros.
> > 
> > This is basically what EXPORT_SIMPLE_DEV_PM_OPS() does by the way.
> > 
> > Cheers,
> > -Paul
> > 
> Ok,
> Well ultimately it's up to Lee as the maintainer of the MFD subsystem.
> 
> But the open-coded #ifdef around "static __maybe_unused" is ugly, so if
> this is going to be a common pattern a new macro would be nice.

I like to avoid #ifery in C files wherever possible.

-- 
DEPRECATED: Please use lee@kernel.org

  reply	other threads:[~2022-08-08 14:47 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-07 14:52 [PATCH 00/28] mfd: Remove #ifdef guards for PM functions Paul Cercueil
2022-08-07 14:52 ` [PATCH 01/28] mfd: 88pm80x: Remove #ifdef guards for PM related functions Paul Cercueil
2022-08-07 14:52 ` [PATCH 02/28] mfd: aat2870: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 03/28] mfd: adp5520: " Paul Cercueil
2022-08-08  7:46   ` Hennerich, Michael
2022-08-07 14:52 ` [PATCH 04/28] mfd: max8925-i2c: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 05/28] mfd: mt6397-irq: " Paul Cercueil
2022-08-07 14:52   ` Paul Cercueil
2022-08-07 14:52 ` [PATCH 06/28] mfd: pcf50633: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 07/28] mfd: rc5t583-irq: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 08/28] mfd: stpmic1: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 09/28] mfd: ucb1x00: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 10/28] mfd: 88pm860x: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 11/28] mfd: intel_soc_pmic: " Paul Cercueil
2022-08-07 15:50   ` Andy Shevchenko
2022-08-07 15:58     ` Paul Cercueil
2022-08-08 11:56       ` Andy Shevchenko
2022-08-08 12:13         ` Lee Jones
2022-08-07 14:52 ` [PATCH 12/28] mfd: mcp-sa11x0: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 13/28] mfd: sec: " Paul Cercueil
2022-08-08  9:11   ` Krzysztof Kozlowski
2022-08-08  9:28     ` Paul Cercueil
2022-08-08 10:06       ` Krzysztof Kozlowski
2022-08-08 10:14         ` Paul Cercueil
2022-08-09 15:33     ` Lee Jones
2022-08-09 15:51       ` Krzysztof Kozlowski
2022-08-09 17:26         ` Lee Jones
2022-08-07 14:52 ` [PATCH 14/28] mfd: sm501: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 15/28] mfd: tc6387xb: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 16/28] mfd: tps6586x: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 17/28] mfd: wm8994: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 18/28] mfd: max77620: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 19/28] mfd: t7l66xb: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 20/28] mfd: arizona: " Paul Cercueil
2022-08-07 17:33   ` kernel test robot
2022-08-08  9:53   ` Richard Fitzgerald
2022-08-08 10:06     ` Paul Cercueil
2022-08-08 10:43       ` Richard Fitzgerald
2022-08-08 11:01         ` Paul Cercueil
2022-08-08 14:00           ` Richard Fitzgerald
2022-08-08 14:47             ` Lee Jones [this message]
2022-08-07 14:52 ` [PATCH 21/28] mfd: max14577: " Paul Cercueil
2022-08-08  9:11   ` Krzysztof Kozlowski
2022-08-08 10:06   ` Krzysztof Kozlowski
2022-08-07 14:52 ` [PATCH 22/28] mfd: max77686: " Paul Cercueil
2022-08-08  9:11   ` Krzysztof Kozlowski
2022-08-08 10:06   ` Krzysztof Kozlowski
2022-08-07 14:52 ` [PATCH 23/28] mfd: motorola-cpcap: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 24/28] mfd: sprd-sc27xx: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 25/28] mfd: stmfx: " Paul Cercueil
2022-08-07 14:52   ` Paul Cercueil
2022-08-07 16:00   ` kernel test robot
2022-08-07 16:00     ` kernel test robot
2022-08-07 18:15   ` kernel test robot
2022-08-07 18:15     ` kernel test robot
2022-08-07 14:52 ` [PATCH 26/28] mfd: stmpe: " Paul Cercueil
2022-08-07 14:52   ` Paul Cercueil
2022-08-07 16:42   ` kernel test robot
2022-08-07 16:42     ` kernel test robot
2022-08-07 17:13   ` kernel test robot
2022-08-07 17:13     ` kernel test robot
2022-08-07 14:52 ` [PATCH 27/28] mfd: tc3589x: " Paul Cercueil
2022-08-07 14:52 ` [PATCH 28/28] mfd: tc6393xb: " Paul Cercueil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YvEh53o4I3Q6+zho@google.com \
    --to=lee.jones@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=paul@crapouillou.net \
    --cc=rf@opensource.cirrus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.