On Wed, Jan 5, 2022 at 5:32 PM Paul Cercueil <paul@xxxxxxxxxxxxxxx> wrote: > > > > Le mer., janv. 5 2022 at 10:17:37 +0000, Jonathan Cameron > <Jonathan.Cameron@xxxxxxxxxx> a écrit : > > On Tue, 4 Jan 2022 21:42:06 +0000 > > Paul Cercueil <paul@xxxxxxxxxxxxxxx> 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!
