linux-kernel - Re: [RFC PATCH 3/3] mmc: jz4740: Use pm_sleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1582558869.3.4@crapouillou.net>
Date:   Mon, 24 Feb 2020 12:41:09 -0300
From:   Paul Cercueil <paul@...pouillou.net>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        od@...c.me, Linux PM <linux-pm@...r.kernel.org>,
        linux-mmc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 3/3] mmc: jz4740: Use pm_sleep_ptr() macro

Hi Ulf,


Le jeu., févr. 20, 2020 at 14:38, Ulf Hansson <ulf.hansson@...aro.org> 
a écrit :
> On Tue, 11 Feb 2020 at 17:03, Paul Cercueil <paul@...pouillou.net> 
> wrote:
>> 
>>  Use the newly introduced pm_sleep_ptr() macro to simplify the code.
>> 
>>  Signed-off-by: Paul Cercueil <paul@...pouillou.net>
>>  ---
>>   drivers/mmc/host/jz4740_mmc.c | 12 +++---------
>>   1 file changed, 3 insertions(+), 9 deletions(-)
>> 
>>  diff --git a/drivers/mmc/host/jz4740_mmc.c 
>> b/drivers/mmc/host/jz4740_mmc.c
>>  index fbae87d1f017..09554f9831de 100644
>>  --- a/drivers/mmc/host/jz4740_mmc.c
>>  +++ b/drivers/mmc/host/jz4740_mmc.c
>>  @@ -1099,24 +1099,18 @@ static int jz4740_mmc_remove(struct 
>> platform_device *pdev)
>>          return 0;
>>   }
>> 
>>  -#ifdef CONFIG_PM_SLEEP
>>  -
>>  -static int jz4740_mmc_suspend(struct device *dev)
>>  +static int __maybe_unused jz4740_mmc_suspend(struct device *dev)
>>   {
>>          return pinctrl_pm_select_sleep_state(dev);
>>   }
>> 
>>  -static int jz4740_mmc_resume(struct device *dev)
>>  +static int __maybe_unused jz4740_mmc_resume(struct device *dev)
>>   {
>>          return pinctrl_select_default_state(dev);
>>   }
>> 
>>   static SIMPLE_DEV_PM_OPS(jz4740_mmc_pm_ops, jz4740_mmc_suspend,
>>          jz4740_mmc_resume);
>>  -#define JZ4740_MMC_PM_OPS (&jz4740_mmc_pm_ops)
>>  -#else
>>  -#define JZ4740_MMC_PM_OPS NULL
>>  -#endif
> 
> All of the above code can be simplified in this way, without having to
> convert into using the new pm_sleep_ptr() macro, below.
> 
> The only "penalty" would be that, the struct dev_pm_ops
> (jz4740_mmc_pm_ops) would then be referenced even when CONFIG_PM* is
> unset, thus the compiler would be able to throw it away.
> 
> Just wanted to point this out.

Yes, what I had in mind with these macros is that in general the 
suspend/resume functions should not be conditionally compiled, as they 
might have errors which would only appear with specific configs, and 
instead should be always compiled but thrown away by the compiler if 
unused.

>> 
>>   static struct platform_driver jz4740_mmc_driver = {
>>          .probe = jz4740_mmc_probe,
>>  @@ -1124,7 +1118,7 @@ static struct platform_driver 
>> jz4740_mmc_driver = {
>>          .driver = {
>>                  .name = "jz4740-mmc",
>>                  .of_match_table = of_match_ptr(jz4740_mmc_of_match),
>>  -               .pm = JZ4740_MMC_PM_OPS,
>>  +               .pm = pm_sleep_ptr(&jz4740_mmc_pm_ops),
> 
> If the driver would have runtime suspend/resume callbacks, then it
> would need the use the pm_ptr() macro instead, I guess.
> 
>>          },
>>   };
>> 
>>  --
>>  2.25.0
>> 
> 
> My overall feeling is that this series improves the code/behaviour,
> but I am also a bit worried about adding yet another pair of macros
> for dealing with CONFIG_PM* callbacks as it could add more confusion.
> 
> An option could be to introduce only the pm_ptr() macro, then skip the
> optimization that pm_sleep_ptr() gives. This could make it easier to
> use, as you wouldn't need to decide between two macros. Just a
> thought.

One macro would be better than none.

Cheers,
-Paul

> I don't know what Rafael's thinks about this, let's see if he has some
> other ideas.
> 
> Kind regards
> Uffe