| Message ID | 20220104214214.198843-1-paul@crapouillou.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | DEV_PM_OPS macros rework | expand |
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. It would slow down a few patches I have queued up behind this, but most of them would be unaffected so it wouldn't annoy me too much. Can't speak for others however! Jonathan > > Cheers, > -Paul > > > Paul Cercueil (8): > PM: core: Remove DEFINE_UNIVERSAL_DEV_PM_OPS() macro > PM: core: Remove static qualifier in DEFINE_SIMPLE_DEV_PM_OPS macro > PM: core: Add EXPORT[_GPL]_SIMPLE_DEV_PM_OPS macros > PM: runtime: Add DEFINE_RUNTIME_DEV_PM_OPS() macro > PM: runtime: Add EXPORT[_GPL]_RUNTIME_DEV_PM_OPS macros > mmc: mxc: Make dev_pm_ops struct static > mmc: jz4740: Make dev_pm_ops struct static > iio: gyro: mpu3050: Use new PM macros > > drivers/iio/gyro/mpu3050-core.c | 13 +++----- > drivers/iio/gyro/mpu3050-i2c.c | 2 +- > drivers/mmc/host/jz4740_mmc.c | 4 +-- > drivers/mmc/host/mxcmmc.c | 2 +- > include/linux/pm.h | 53 +++++++++++++++++++++++---------- > include/linux/pm_runtime.h | 21 +++++++++++++ > 6 files changed, 67 insertions(+), 28 deletions(-) >
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? -Paul > It would slow down a few patches I have queued up behind this, but > most of them > would be unaffected so it wouldn't annoy me too much. Can't speak for > others > however! > > Jonathan > >> >> Cheers, >> -Paul >> >> >> Paul Cercueil (8): >> PM: core: Remove DEFINE_UNIVERSAL_DEV_PM_OPS() macro >> PM: core: Remove static qualifier in DEFINE_SIMPLE_DEV_PM_OPS >> macro >> PM: core: Add EXPORT[_GPL]_SIMPLE_DEV_PM_OPS macros >> PM: runtime: Add DEFINE_RUNTIME_DEV_PM_OPS() macro >> PM: runtime: Add EXPORT[_GPL]_RUNTIME_DEV_PM_OPS macros >> mmc: mxc: Make dev_pm_ops struct static >> mmc: jz4740: Make dev_pm_ops struct static >> iio: gyro: mpu3050: Use new PM macros >> >> drivers/iio/gyro/mpu3050-core.c | 13 +++----- >> drivers/iio/gyro/mpu3050-i2c.c | 2 +- >> drivers/mmc/host/jz4740_mmc.c | 4 +-- >> drivers/mmc/host/mxcmmc.c | 2 +- >> include/linux/pm.h | 53 >> +++++++++++++++++++++++---------- >> include/linux/pm_runtime.h | 21 +++++++++++++ >> 6 files changed, 67 insertions(+), 28 deletions(-) >> >
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!