Hi,
Le dim., nov. 28 2021 at 10:26:40 +0100, Arnd Bergmann <arnd@xxxxxxxx>
a écrit :
On Sat, Nov 27, 2021 at 7:02 PM Jonathan Cameron <jic23@xxxxxxxxxx>
wrote:
On Tue, 23 Nov 2021 22:11:08 +0000 Paul Cercueil
<paul@xxxxxxxxxxxxxxx> wrote:
?
> The problem then is that the SET_*_PM_OPS macros are defined
> differently according to CONFIG_PM, so their definition would
need to
> be changed to use the (redefined) pm_ptr() macro and a
corresponding
> pm_sleep_ptr() macro.
Small question here. Why would these macros need to use pm_ptr()
macro at all?
Why not just stop them being conditional on CONFIG_PM at all and
let dead
code removal kill them off for us? You might want to do something
different
for the CONFIG_PM_SLEEP ones though if we care about having it that
fine
grained.
Agreed, there is no need to use pm_ptr() inside of the new macros, it
would just
be convenient to define them this way.
In that case all the callbacks of a dev_pm_ops will be compiled even
though .suspend/.resume are only for CONFIG_PM_SLEEP.
The driver could do:
.dev.pm = pm_sleep_ptr(&my_pm_sleep_ops),
But that means the driver's dev needs to be aware that pm_sleep_ptr()
is for simple PM, and pm_ptr() if runtime PM is used.
The alternative I suggested was to use pm_sleep_ptr() inside the
SET_*_PM_OPS macros (and not pm_ptr() which wouldn't make much sense, I
agree) so that the callbacks would be included only when
CONFIG_PM_SLEEP is set; and the drivers would only ever use pm_ptr()
for their .dev.pm.
I'm slightly in favor of the first solution, just because it would make
the kernel smaller if !CONFIG_PM_SLEEP as you wouldn't have an empty
dev_pm_ops struct.
Cheers,
-Paul
