lkml.org 
[lkml]   [2022]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 0/8] DEV_PM_OPS macros rework
On Wed, Jan 5, 2022 at 5:32 PM Paul Cercueil <paul@crapouillou.net> wrote:
>
>
>
> Le mer., janv. 5 2022 at 10:17:37 +0000, Jonathan Cameron
> <Jonathan.Cameron@Huawei.com> a écrit :
> > On Tue, 4 Jan 2022 21:42:06 +0000
> > Paul Cercueil <paul@crapouillou.net> wrote:
> >
> >> Hi,
> >>
> >> This set of commits rework a bit the *_DEV_PM_OPS() macros that were
> >> introduced recently.
> >>
> >> - Remove the DEFINE_UNIVERSAL_DEV_PM_OPS() macro, since I highly
> >> doubt
> >> anything is going to use it. The macro it replaces
> >> (UNIVERSAL_DEV_PM_OPS) seems to only be used incorrectly in code
> >> that
> >> hasn't been updated in ages.
> >>
> >> - Remove the static qualifier in DEFINE_SIMPLE_DEV_PM_OPS, so that
> >> the
> >> macro is more in line with what's done elsewhere in the kernel.
> >>
> >> - Add a DEFINE_RUNTIME_DEV_PM_OPS() macro, for use with drivers
> >> that use
> >> runtime PM, and use
> >> runtime_pm_force_suspend/runtime_pm_force_resume
> >> as their system sleep callbacks.
> >>
> >> - Add EXPORT_*_DEV_PM_OPS macros, which can be used for when the
> >> underlying dev_pm_ops is to be exported. With CONFIG_PM set, the
> >> symbol is exported as you would expect. With CONFIG_PM disabled,
> >> the
> >> dev_pm_ops is garbage-collected along with the suspend/resume
> >> callbacks.
> >>
> >> - Update the two places which used DEFINE_SIMPLE_DEV_PM_OPS, to add
> >> back
> >> the "static" qualifier that was stripped from the macro.
> >>
> >> - Update one driver to use EXPORT_RUNTIME_DEV_PM_OPS(), just to
> >> showcase
> >> how to use this macro in the case where a dev_pm_ops is to be
> >> exported.
> >> Note that the driver itself is GPL, and the symbol is only used
> >> within
> >> a GPL driver, so I would assume the symbol would be exported as
> >> GPL.
> >> But it was not the case in the original code, so I did not change
> >> the
> >> behaviour.
> >>
> >> Feedback welcome.
> >
> > Comments on individual patches (in particular bad pick for that final
> > example ;)
> >
> > Given how late we are in the cycle, I'd argue we 'need' patches 2 (+
> > 5,6 which
> > should probably be all one patch to avoid introducing then fixing a
> > warning in
> > different patches). The others could wait for the following cycle if
> > needed.
>
> Ok, should I V2 with patches 2/5/6 merged together?

Yes, please!

\
 
 \ /
  Last update: 2022-01-05 18:39    [W:2.216 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site