Re: [PATCH 0/8] DEV_PM_OPS macros rework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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?

-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(-)







[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux