| Message ID | 20211123211019.2271440-1-jic23@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: Tree wide switch from CONFIG_PM* to __maybe_unused etc. | expand |
Hi Jonathan, Cc'd Arnd who may have some interest in the topic. Le mar., nov. 23 2021 at 21:09:30 +0000, Jonathan Cameron <jic23@kernel.org> a écrit : > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Note this series includes many drivers that are quite old and I'm not > sure have active maintainers. Hence if anyone has time to look at > some > of these beyond their own drivers and sanity check them it would be > much > appreciated! > > Two motivations behind this set. > 1 - General code reduction and improvement in readability in these > drivers. > 2 - Reduce change I'll have to ask people to change how they do this > in > future patches. > > Mostly this is just a case of letting the compiler work out it can > remove > the PM related functions rather than using #ifdefs in the code to do > so. > > The __maybe_unused markings make it clear we are intentionally > building > functions that the compiler can see are unused and remove in some > build > configurations. > > The new pm_ptr() macro is rather convenient to got futher than many of > the drivers were and when CONFIG_PM is not define ensure that the > struct dev_pm_ops can also be removed. Note there is a subtlty in > that > we only remove that whe CONFIG_PM is not defined whereas a few of > these > drivers were using CONFIG_PM_SLEEP which is a tighter condition (will > remove the structure in more configurations). I think that's a small > price to pay for the convenience this macro brings. > > I did this set as one patch per driver, as personally I prefer that > option for all but the most trivial patches because it makes backports > that cross with this series simpler and also avoid the complex > tag giving we get for sets touching code from many authors. > > All comments welcome. One word about the pm_ptr() macro. Right now it's defined as: #ifdef CONFIG_PM #define pm_ptr(_ptr) (_ptr) #else #define pm_ptr(_ptr) NULL #endif It could be possible to define it like this instead: #define pm_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM), (_ptr)) The difference is that if !CONFIG_PM, in the first case the (_ptr) is not visible by the compiler and the __maybe_unused is required, while in the second case the (_ptr) is always visible by the compiler, but discarded as dead code. The reason we'd want that is the same reason we use IS_ENABLED() instead of macro guards; and you wouldn't need the __maybe_unused attribute anywhere. 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. Unfortunately since the SET_*_PM_OPS macros are used everywhere with code wrapped around #ifdef CONFIG_PM guards, it wouldn't be easy to change them, and it would just be easier to introduce new macros. The patchset looks fine as-is and I am not asking you to work on anything I just said, I just thought it was worth mentioning. Cheers, -Paul > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> > Cc: Anson Huang <anson.huang@nxp.com> > Cc: Brian Masney <masneyb@onstation.org> > Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com> > Cc: Hans de Goede <hdegoede@redhat.com> > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> > Cc: Icenowy Zheng <icenowy@aosc.io> > Cc: Jonathan Albrieux <jonathan.albrieux@gmail.com> > Cc: Krzysztof Kozlowski <krzk@kernel.org> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Luca Weiss <luca@z3ntu.xyz> > Cc: Ludovic Desroches <ludovic.desroches@microchip.com> > Cc: Manivannan Sadhasivam <mani@kernel.org> > Cc: Martijn Braam <martijn@brixit.nl> > Cc: Maslov Dmitry <maslovdmitry@seeed.cc> > Cc: Matt Ranostay <matt.ranostay@konsulko.com > Cc: Olivier Moysan <olivier.moysan@foss.st.com> > Cc: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com> > Cc: Vaishnav M A <vaishnav@beagleboard.org> > > > Jonathan Cameron (49): > iio:accel:da311: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:accel:da280: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:accel:dmard06: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:accel:dmard10: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:accel:mc3230: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:accel:mma7660: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:accel:mma9551: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:accel:mma9553: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:accel:stk8ba50: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:accel:kxsd9: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:adc:ab8500: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:adc:ad7606: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:adc:at91-adc: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:adc:exynos_adc: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:adc:palmas_gpadc: Switch from CONFIG_PM_SLEEP guards to > pm_ptr() / > __maybe_unused > iio:adc:stm32:Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:adc:rcar: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:adc:rockchip: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:adc:twl6030: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:adc:vf610: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:common:ssp: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:dac:vf610: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:apds9300: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:bh1780: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:light:cm3232: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:isl29018: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:isl29125: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:jsa1212: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:ltr501: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:stk3310: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:tcs3414: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:tcs3472: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:tsl2563: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:tsl4531: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:light:us5182: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:magn:ak8975: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:magn:hmc5843: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:magn:mag3110: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:magn:mmc35240: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > __maybe_unused > iio:pressure:mpl3115: Switch from CONFIG_PM_SLEEP guards to > pm_ptr() / > __maybe_unused > iio:pressure:bmp280: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:proximity:as3935: Switch from CONFIG_PM_SLEEP guards to > pm_ptr() / > __maybe_unused > iio:proximity:pulsedlight: Switch from CONFIG_PM guards to pm_ptr() > / > __maybe_unused > iio:proximity:rfd77492: Switch from CONFIG_PM_SLEEP guards to > pm_ptr() > / __maybe_unused > iio:proximity:sx9500: Switch from CONFIG_PM_SLEEP guards to > pm_ptr() / > __maybe_unused > iio:temperature:tmp006: Switch from CONFIG_PM_SLEEP guards to > pm_ptr() > / __maybe_unused > iio:temperature:tmp007: Switch from CONFIG_PM_SLEEP guards to > pm_ptr() > / __maybe_unused > iio:gyro:mpu3050: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > iio:chemical:atlas: Switch from CONFIG_PM guards to pm_ptr() / > __maybe_unused > > drivers/iio/accel/da280.c | 6 ++---- > drivers/iio/accel/da311.c | 8 +++----- > drivers/iio/accel/dmard06.c | 12 ++++-------- > drivers/iio/accel/dmard10.c | 9 ++++----- > drivers/iio/accel/kxsd9-i2c.c | 2 +- > drivers/iio/accel/kxsd9-spi.c | 2 +- > drivers/iio/accel/kxsd9.c | 8 +++----- > drivers/iio/accel/mc3230.c | 8 +++----- > drivers/iio/accel/mma7660.c | 12 +++--------- > drivers/iio/accel/mma9551.c | 16 > ++++++---------- > drivers/iio/accel/mma9553.c | 16 > ++++++---------- > drivers/iio/accel/stk8ba50.c | 12 +++--------- > drivers/iio/adc/ab8500-gpadc.c | 10 ++++------ > drivers/iio/adc/ad7606.c | 8 ++------ > drivers/iio/adc/ad7606.h | 5 ----- > drivers/iio/adc/ad7606_par.c | 2 +- > drivers/iio/adc/ad7606_spi.c | 2 +- > drivers/iio/adc/at91_adc.c | 8 +++----- > drivers/iio/adc/exynos_adc.c | 8 +++----- > drivers/iio/adc/palmas_gpadc.c | 14 ++++++-------- > drivers/iio/adc/rcar-gyroadc.c | 10 ++++------ > drivers/iio/adc/rockchip_saradc.c | 8 +++----- > drivers/iio/adc/stm32-adc-core.c | 12 +++++------- > drivers/iio/adc/stm32-adc.c | 16 > ++++++---------- > drivers/iio/adc/twl6030-gpadc.c | 8 +++----- > drivers/iio/adc/vf610_adc.c | 8 +++----- > drivers/iio/chemical/atlas-sensor.c | 10 ++++------ > drivers/iio/common/ssp_sensors/ssp_dev.c | 12 ++++-------- > drivers/iio/dac/vf610_dac.c | 8 +++----- > drivers/iio/gyro/mpu3050-core.c | 8 +++----- > drivers/iio/gyro/mpu3050-i2c.c | 2 +- > drivers/iio/light/apds9300.c | 11 +++-------- > drivers/iio/light/bh1780.c | 10 ++++------ > drivers/iio/light/cm3232.c | 13 ++++--------- > drivers/iio/light/isl29018.c | 11 +++-------- > drivers/iio/light/isl29125.c | 8 +++----- > drivers/iio/light/jsa1212.c | 12 +++--------- > drivers/iio/light/ltr501.c | 8 +++----- > drivers/iio/light/stk3310.c | 12 +++--------- > drivers/iio/light/tcs3414.c | 8 +++----- > drivers/iio/light/tcs3472.c | 8 +++----- > drivers/iio/light/tsl2563.c | 11 +++-------- > drivers/iio/light/tsl4531.c | 11 +++-------- > drivers/iio/light/us5182d.c | 10 ++++------ > drivers/iio/magnetometer/ak8975.c | 10 ++++------ > drivers/iio/magnetometer/hmc5843.h | 5 ----- > drivers/iio/magnetometer/hmc5843_i2c.c | 2 +- > drivers/iio/magnetometer/hmc5843_spi.c | 2 +- > drivers/iio/magnetometer/mag3110.c | 11 +++-------- > drivers/iio/magnetometer/mmc35240.c | 12 ++++-------- > drivers/iio/pressure/bmp280-core.c | 6 ++---- > drivers/iio/pressure/bmp280-i2c.c | 2 +- > drivers/iio/pressure/bmp280-spi.c | 2 +- > drivers/iio/pressure/mpl3115.c | 11 +++-------- > drivers/iio/proximity/as3935.c | 12 +++--------- > .../iio/proximity/pulsedlight-lidar-lite-v2.c | 10 ++++------ > drivers/iio/proximity/rfd77402.c | 8 +++----- > drivers/iio/proximity/sx9500.c | 12 ++++-------- > drivers/iio/temperature/tmp006.c | 8 +++----- > drivers/iio/temperature/tmp007.c | 8 +++----- > 60 files changed, 180 insertions(+), 344 deletions(-) > > -- > 2.34.0 >
On Tue, Nov 23, 2021 at 09:09:30PM +0000, Jonathan Cameron wrote: > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Note this series includes many drivers that are quite old and I'm not > sure have active maintainers. Hence if anyone has time to look at some > of these beyond their own drivers and sanity check them it would be much > appreciated! > > Two motivations behind this set. > 1 - General code reduction and improvement in readability in these drivers. > 2 - Reduce change I'll have to ask people to change how they do this in > future patches. > > Mostly this is just a case of letting the compiler work out it can remove > the PM related functions rather than using #ifdefs in the code to do so. > > The __maybe_unused markings make it clear we are intentionally building > functions that the compiler can see are unused and remove in some build > configurations. > > The new pm_ptr() macro is rather convenient to got futher than many of > the drivers were and when CONFIG_PM is not define ensure that the > struct dev_pm_ops can also be removed. Note there is a subtlty in that > we only remove that whe CONFIG_PM is not defined whereas a few of these > drivers were using CONFIG_PM_SLEEP which is a tighter condition (will > remove the structure in more configurations). I think that's a small > price to pay for the convenience this macro brings. > > I did this set as one patch per driver, as personally I prefer that > option for all but the most trivial patches because it makes backports > that cross with this series simpler and also avoid the complex > tag giving we get for sets touching code from many authors. > > All comments welcome. Nice cleanup! Assuming that you add the missing pm_ptr() to patch 2 (iio:accel:da280) you can add this to the series: Reviewed-by: Brian Masney <bmasney@redhat.com>
On Tue, Nov 23, 2021 at 11:11 PM Paul Cercueil <paul@crapouillou.net> wrote: > > One word about the pm_ptr() macro. Right now it's defined as: > #ifdef CONFIG_PM > #define pm_ptr(_ptr) (_ptr) > #else > #define pm_ptr(_ptr) NULL > #endif > > It could be possible to define it like this instead: > #define pm_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM), (_ptr)) > > The difference is that if !CONFIG_PM, in the first case the (_ptr) is > not visible by the compiler and the __maybe_unused is required, while > in the second case the (_ptr) is always visible by the compiler, but > discarded as dead code. The reason we'd want that is the same reason we > use IS_ENABLED() instead of macro guards; and you wouldn't need the > __maybe_unused attribute anywhere. That sounds like a great idea. I see there are only 12 users of pm_ptr at the moment, so auditing all of these should not be a problem. I gave it a brief look and found that we probably only need to fix drivers/net/ethernet/realtek/r8169_main.c if we change the definition. > 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. Unfortunately since the SET_*_PM_OPS macros are > used everywhere with code wrapped around #ifdef CONFIG_PM guards, it > wouldn't be easy to change them, and it would just be easier to > introduce new macros. Right, this is what we've discussed multiple times, and I think everyone agreed we should do this, but so far we could not come up with a name for the new macro, and changing the macro in place is not practical unless we change hundreds of drivers in the same way as the iio series first. Arnd
On Wed, 24 Nov 2021 08:29:40 +0100 Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Nov 23, 2021 at 11:11 PM Paul Cercueil <paul@crapouillou.net> wrote: > > > > One word about the pm_ptr() macro. Right now it's defined as: > > #ifdef CONFIG_PM > > #define pm_ptr(_ptr) (_ptr) > > #else > > #define pm_ptr(_ptr) NULL > > #endif > > > > It could be possible to define it like this instead: > > #define pm_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM), (_ptr)) > > > > The difference is that if !CONFIG_PM, in the first case the (_ptr) is > > not visible by the compiler and the __maybe_unused is required, while > > in the second case the (_ptr) is always visible by the compiler, but > > discarded as dead code. The reason we'd want that is the same reason we > > use IS_ENABLED() instead of macro guards; and you wouldn't need the > > __maybe_unused attribute anywhere. > > That sounds like a great idea. I see there are only 12 users of pm_ptr at > the moment, so auditing all of these should not be a problem. > > I gave it a brief look and found that we probably only need to fix > drivers/net/ethernet/realtek/r8169_main.c if we change the definition. Cool. > > > 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. Unfortunately since the SET_*_PM_OPS macros are > > used everywhere with code wrapped around #ifdef CONFIG_PM guards, it > > wouldn't be easy to change them, and it would just be easier to > > introduce new macros. > > Right, this is what we've discussed multiple times, and I think everyone > agreed we should do this, but so far we could not come up with a name > for the new macro, and changing the macro in place is not practical unless > we change hundreds of drivers in the same way as the iio series first. Nasty indeed and I'm not sure how scriptable either as lots of subtle variants unfortunately. I'm cynical - don't need a good name. *_OPS2 works fine for me as long as the docs are good. Jonathan > > Arnd
Le mer., nov. 24 2021 at 10:11:13 +0000, Jonathan Cameron <Jonathan.Cameron@Huawei.com> a écrit : > On Wed, 24 Nov 2021 08:29:40 +0100 > Arnd Bergmann <arnd@arndb.de> wrote: > >> On Tue, Nov 23, 2021 at 11:11 PM Paul Cercueil >> <paul@crapouillou.net> wrote: >> > >> > One word about the pm_ptr() macro. Right now it's defined as: >> > #ifdef CONFIG_PM >> > #define pm_ptr(_ptr) (_ptr) >> > #else >> > #define pm_ptr(_ptr) NULL >> > #endif >> > >> > It could be possible to define it like this instead: >> > #define pm_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM), (_ptr)) >> > >> > The difference is that if !CONFIG_PM, in the first case the >> (_ptr) is >> > not visible by the compiler and the __maybe_unused is required, >> while >> > in the second case the (_ptr) is always visible by the compiler, >> but >> > discarded as dead code. The reason we'd want that is the same >> reason we >> > use IS_ENABLED() instead of macro guards; and you wouldn't need >> the >> > __maybe_unused attribute anywhere. >> >> That sounds like a great idea. I see there are only 12 users of >> pm_ptr at >> the moment, so auditing all of these should not be a problem. >> >> I gave it a brief look and found that we probably only need to fix >> drivers/net/ethernet/realtek/r8169_main.c if we change the >> definition. > > Cool. > >> >> > 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. Unfortunately since the SET_*_PM_OPS macros >> are >> > used everywhere with code wrapped around #ifdef CONFIG_PM guards, >> it >> > wouldn't be easy to change them, and it would just be easier to >> > introduce new macros. >> >> Right, this is what we've discussed multiple times, and I think >> everyone >> agreed we should do this, but so far we could not come up with a >> name >> for the new macro, and changing the macro in place is not practical >> unless >> we change hundreds of drivers in the same way as the iio series >> first. > > Nasty indeed and I'm not sure how scriptable either as lots of subtle > variants > unfortunately. > > I'm cynical - don't need a good name. *_OPS2 works fine for me as > long as > the docs are good. We could just remove the SET_ prefix, SET_SYSTEM_SLEEP_PM_OPS -> SYSTEM_SLEEP_PM_OPS, Or would that be too confusing? -Paul
On Wed, Nov 24, 2021 at 11:11 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > On Wed, 24 Nov 2021 08:29:40 +0100 Arnd Bergmann <arnd@arndb.de> 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. Unfortunately since the SET_*_PM_OPS macros are > > > used everywhere with code wrapped around #ifdef CONFIG_PM guards, it > > > wouldn't be easy to change them, and it would just be easier to > > > introduce new macros. > > > > Right, this is what we've discussed multiple times, and I think everyone > > agreed we should do this, but so far we could not come up with a name > > for the new macro, and changing the macro in place is not practical unless > > we change hundreds of drivers in the same way as the iio series first. > > Nasty indeed and I'm not sure how scriptable either as lots of subtle variants > unfortunately. The minor variants (late, noirq) are actually the easy part, for the macros that have fewer users, we can just have one patch per macro that changes it treewide. For SET_SYSTEM_SLEEP_PM_OPS/SET_RUNTIME_PM_OPS and their DEV_PM_OPS variants, this would be a lot harder: $ for i in SET_SYSTEM_SLEEP_PM_OPS SET_LATE_SYSTEM_SLEEP_PM_OPS SET_NOIRQ_SYSTEM_SLEEP_PM_OPS SET_RUNTIME_PM_OPS SIMPLE_DEV_PM_OPS UNIVERSAL_DEV_PM_OPS ; do echo `git grep -wl $i | wc -l` $i ; done 459 SET_SYSTEM_SLEEP_PM_OPS 51 SET_LATE_SYSTEM_SLEEP_PM_OPS 59 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS 497 SET_RUNTIME_PM_OPS 797 SIMPLE_DEV_PM_OPS 20 UNIVERSAL_DEV_PM_OPS About half of those actually use an #ifdef, while the other half does not: $ git grep -wl 'SET_SYSTEM_SLEEP_PM_OPS\|SET_RUNTIME_PM_OPS\|SIMPLE_DEV_PM_OPS\|UNIVERSAL_DEV_PM_OPS' | xargs grep -l CONFIG_PM | wc -l 712 $ git grep -wl 'SET_SYSTEM_SLEEP_PM_OPS\|SET_RUNTIME_PM_OPS\|SIMPLE_DEV_PM_OPS\|UNIVERSAL_DEV_PM_OPS' | xargs grep -L CONFIG_PM | wc -l 745 If we rename the macros in the first half of this using a script, then we should be able to change the behavior of the normal macros to use the new pm_ptr(). Arnd
Le mer., nov. 24 2021 at 13:23:47 +0100, Arnd Bergmann <arnd@arndb.de> a écrit : > On Wed, Nov 24, 2021 at 11:11 AM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: >> On Wed, 24 Nov 2021 08:29:40 +0100 Arnd Bergmann <arnd@arndb.de> >> 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. Unfortunately since the SET_*_PM_OPS >> macros are >> > > used everywhere with code wrapped around #ifdef CONFIG_PM >> guards, it >> > > wouldn't be easy to change them, and it would just be easier to >> > > introduce new macros. >> > >> > Right, this is what we've discussed multiple times, and I think >> everyone >> > agreed we should do this, but so far we could not come up with a >> name >> > for the new macro, and changing the macro in place is not >> practical unless >> > we change hundreds of drivers in the same way as the iio series >> first. >> >> Nasty indeed and I'm not sure how scriptable either as lots of >> subtle variants >> unfortunately. > > The minor variants (late, noirq) are actually the easy part, for the > macros that > have fewer users, we can just have one patch per macro that changes > it treewide. > For SET_SYSTEM_SLEEP_PM_OPS/SET_RUNTIME_PM_OPS and their > DEV_PM_OPS variants, this would be a lot harder: > > $ for i in SET_SYSTEM_SLEEP_PM_OPS SET_LATE_SYSTEM_SLEEP_PM_OPS > SET_NOIRQ_SYSTEM_SLEEP_PM_OPS SET_RUNTIME_PM_OPS SIMPLE_DEV_PM_OPS > UNIVERSAL_DEV_PM_OPS ; do echo `git grep -wl $i | wc -l` $i ; done > > 459 SET_SYSTEM_SLEEP_PM_OPS > 51 SET_LATE_SYSTEM_SLEEP_PM_OPS > 59 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS > 497 SET_RUNTIME_PM_OPS > 797 SIMPLE_DEV_PM_OPS > 20 UNIVERSAL_DEV_PM_OPS > > About half of those actually use an #ifdef, while the other half does > not: > > $ git grep -wl > 'SET_SYSTEM_SLEEP_PM_OPS\|SET_RUNTIME_PM_OPS\|SIMPLE_DEV_PM_OPS\|UNIVERSAL_DEV_PM_OPS' > | xargs grep -l CONFIG_PM | wc -l > 712 > $ git grep -wl > 'SET_SYSTEM_SLEEP_PM_OPS\|SET_RUNTIME_PM_OPS\|SIMPLE_DEV_PM_OPS\|UNIVERSAL_DEV_PM_OPS' > | xargs grep -L CONFIG_PM | wc -l > 745 > > If we rename the macros in the first half of this using a script, > then we should > be able to change the behavior of the normal macros to use the new > pm_ptr(). So you want to rename the current macros (to e.g. *_PM_OPS_LEGACY) everywhere so that new ones can be defined? What about we introduce new macros, and just deprecate the old ones (with e.g. a checkpatch warning)? That would be way less work. -Paul
On Tue, 23 Nov 2021 22:11:08 +0000 Paul Cercueil <paul@crapouillou.net> wrote: > Hi Jonathan, > > Cc'd Arnd who may have some interest in the topic. > > Le mar., nov. 23 2021 at 21:09:30 +0000, Jonathan Cameron > <jic23@kernel.org> a écrit : > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > Note this series includes many drivers that are quite old and I'm not > > sure have active maintainers. Hence if anyone has time to look at > > some > > of these beyond their own drivers and sanity check them it would be > > much > > appreciated! > > > > Two motivations behind this set. > > 1 - General code reduction and improvement in readability in these > > drivers. > > 2 - Reduce change I'll have to ask people to change how they do this > > in > > future patches. > > > > Mostly this is just a case of letting the compiler work out it can > > remove > > the PM related functions rather than using #ifdefs in the code to do > > so. > > > > The __maybe_unused markings make it clear we are intentionally > > building > > functions that the compiler can see are unused and remove in some > > build > > configurations. > > > > The new pm_ptr() macro is rather convenient to got futher than many of > > the drivers were and when CONFIG_PM is not define ensure that the > > struct dev_pm_ops can also be removed. Note there is a subtlty in > > that > > we only remove that whe CONFIG_PM is not defined whereas a few of > > these > > drivers were using CONFIG_PM_SLEEP which is a tighter condition (will > > remove the structure in more configurations). I think that's a small > > price to pay for the convenience this macro brings. > > > > I did this set as one patch per driver, as personally I prefer that > > option for all but the most trivial patches because it makes backports > > that cross with this series simpler and also avoid the complex > > tag giving we get for sets touching code from many authors. > > > > All comments welcome. > > One word about the pm_ptr() macro. Right now it's defined as: > #ifdef CONFIG_PM > #define pm_ptr(_ptr) (_ptr) > #else > #define pm_ptr(_ptr) NULL > #endif > > It could be possible to define it like this instead: > #define pm_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM), (_ptr)) > > The difference is that if !CONFIG_PM, in the first case the (_ptr) is > not visible by the compiler and the __maybe_unused is required, while > in the second case the (_ptr) is always visible by the compiler, but > discarded as dead code. The reason we'd want that is the same reason we > use IS_ENABLED() instead of macro guards; and you wouldn't need the > __maybe_unused attribute anywhere. > > 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. Obviously still need new macros to do this, so doesn't change the fundamental question. > Unfortunately since the SET_*_PM_OPS macros are > used everywhere with code wrapped around #ifdef CONFIG_PM guards, it > wouldn't be easy to change them, and it would just be easier to > introduce new macros. > > The patchset looks fine as-is and I am not asking you to work on > anything I just said, I just thought it was worth mentioning. > > Cheers, > -Paul > > > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> > > Cc: Anson Huang <anson.huang@nxp.com> > > Cc: Brian Masney <masneyb@onstation.org> > > Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com> > > Cc: Hans de Goede <hdegoede@redhat.com> > > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> > > Cc: Icenowy Zheng <icenowy@aosc.io> > > Cc: Jonathan Albrieux <jonathan.albrieux@gmail.com> > > Cc: Krzysztof Kozlowski <krzk@kernel.org> > > Cc: Linus Walleij <linus.walleij@linaro.org> > > Cc: Luca Weiss <luca@z3ntu.xyz> > > Cc: Ludovic Desroches <ludovic.desroches@microchip.com> > > Cc: Manivannan Sadhasivam <mani@kernel.org> > > Cc: Martijn Braam <martijn@brixit.nl> > > Cc: Maslov Dmitry <maslovdmitry@seeed.cc> > > Cc: Matt Ranostay <matt.ranostay@konsulko.com > > Cc: Olivier Moysan <olivier.moysan@foss.st.com> > > Cc: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com> > > Cc: Vaishnav M A <vaishnav@beagleboard.org> > > > > > > Jonathan Cameron (49): > > iio:accel:da311: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:accel:da280: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:accel:dmard06: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:accel:dmard10: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:accel:mc3230: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:accel:mma7660: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:accel:mma9551: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:accel:mma9553: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:accel:stk8ba50: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:accel:kxsd9: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:adc:ab8500: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:adc:ad7606: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:adc:at91-adc: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:adc:exynos_adc: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:adc:palmas_gpadc: Switch from CONFIG_PM_SLEEP guards to > > pm_ptr() / > > __maybe_unused > > iio:adc:stm32:Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:adc:rcar: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:adc:rockchip: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:adc:twl6030: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:adc:vf610: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:common:ssp: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:dac:vf610: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:apds9300: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:bh1780: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:light:cm3232: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:isl29018: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:isl29125: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:jsa1212: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:ltr501: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:stk3310: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:tcs3414: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:tcs3472: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:tsl2563: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:tsl4531: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:light:us5182: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:magn:ak8975: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:magn:hmc5843: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:magn:mag3110: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:magn:mmc35240: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / > > __maybe_unused > > iio:pressure:mpl3115: Switch from CONFIG_PM_SLEEP guards to > > pm_ptr() / > > __maybe_unused > > iio:pressure:bmp280: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:proximity:as3935: Switch from CONFIG_PM_SLEEP guards to > > pm_ptr() / > > __maybe_unused > > iio:proximity:pulsedlight: Switch from CONFIG_PM guards to pm_ptr() > > / > > __maybe_unused > > iio:proximity:rfd77492: Switch from CONFIG_PM_SLEEP guards to > > pm_ptr() > > / __maybe_unused > > iio:proximity:sx9500: Switch from CONFIG_PM_SLEEP guards to > > pm_ptr() / > > __maybe_unused > > iio:temperature:tmp006: Switch from CONFIG_PM_SLEEP guards to > > pm_ptr() > > / __maybe_unused > > iio:temperature:tmp007: Switch from CONFIG_PM_SLEEP guards to > > pm_ptr() > > / __maybe_unused > > iio:gyro:mpu3050: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > iio:chemical:atlas: Switch from CONFIG_PM guards to pm_ptr() / > > __maybe_unused > > > > drivers/iio/accel/da280.c | 6 ++---- > > drivers/iio/accel/da311.c | 8 +++----- > > drivers/iio/accel/dmard06.c | 12 ++++-------- > > drivers/iio/accel/dmard10.c | 9 ++++----- > > drivers/iio/accel/kxsd9-i2c.c | 2 +- > > drivers/iio/accel/kxsd9-spi.c | 2 +- > > drivers/iio/accel/kxsd9.c | 8 +++----- > > drivers/iio/accel/mc3230.c | 8 +++----- > > drivers/iio/accel/mma7660.c | 12 +++--------- > > drivers/iio/accel/mma9551.c | 16 > > ++++++---------- > > drivers/iio/accel/mma9553.c | 16 > > ++++++---------- > > drivers/iio/accel/stk8ba50.c | 12 +++--------- > > drivers/iio/adc/ab8500-gpadc.c | 10 ++++------ > > drivers/iio/adc/ad7606.c | 8 ++------ > > drivers/iio/adc/ad7606.h | 5 ----- > > drivers/iio/adc/ad7606_par.c | 2 +- > > drivers/iio/adc/ad7606_spi.c | 2 +- > > drivers/iio/adc/at91_adc.c | 8 +++----- > > drivers/iio/adc/exynos_adc.c | 8 +++----- > > drivers/iio/adc/palmas_gpadc.c | 14 ++++++-------- > > drivers/iio/adc/rcar-gyroadc.c | 10 ++++------ > > drivers/iio/adc/rockchip_saradc.c | 8 +++----- > > drivers/iio/adc/stm32-adc-core.c | 12 +++++------- > > drivers/iio/adc/stm32-adc.c | 16 > > ++++++---------- > > drivers/iio/adc/twl6030-gpadc.c | 8 +++----- > > drivers/iio/adc/vf610_adc.c | 8 +++----- > > drivers/iio/chemical/atlas-sensor.c | 10 ++++------ > > drivers/iio/common/ssp_sensors/ssp_dev.c | 12 ++++-------- > > drivers/iio/dac/vf610_dac.c | 8 +++----- > > drivers/iio/gyro/mpu3050-core.c | 8 +++----- > > drivers/iio/gyro/mpu3050-i2c.c | 2 +- > > drivers/iio/light/apds9300.c | 11 +++-------- > > drivers/iio/light/bh1780.c | 10 ++++------ > > drivers/iio/light/cm3232.c | 13 ++++--------- > > drivers/iio/light/isl29018.c | 11 +++-------- > > drivers/iio/light/isl29125.c | 8 +++----- > > drivers/iio/light/jsa1212.c | 12 +++--------- > > drivers/iio/light/ltr501.c | 8 +++----- > > drivers/iio/light/stk3310.c | 12 +++--------- > > drivers/iio/light/tcs3414.c | 8 +++----- > > drivers/iio/light/tcs3472.c | 8 +++----- > > drivers/iio/light/tsl2563.c | 11 +++-------- > > drivers/iio/light/tsl4531.c | 11 +++-------- > > drivers/iio/light/us5182d.c | 10 ++++------ > > drivers/iio/magnetometer/ak8975.c | 10 ++++------ > > drivers/iio/magnetometer/hmc5843.h | 5 ----- > > drivers/iio/magnetometer/hmc5843_i2c.c | 2 +- > > drivers/iio/magnetometer/hmc5843_spi.c | 2 +- > > drivers/iio/magnetometer/mag3110.c | 11 +++-------- > > drivers/iio/magnetometer/mmc35240.c | 12 ++++-------- > > drivers/iio/pressure/bmp280-core.c | 6 ++---- > > drivers/iio/pressure/bmp280-i2c.c | 2 +- > > drivers/iio/pressure/bmp280-spi.c | 2 +- > > drivers/iio/pressure/mpl3115.c | 11 +++-------- > > drivers/iio/proximity/as3935.c | 12 +++--------- > > .../iio/proximity/pulsedlight-lidar-lite-v2.c | 10 ++++------ > > drivers/iio/proximity/rfd77402.c | 8 +++----- > > drivers/iio/proximity/sx9500.c | 12 ++++-------- > > drivers/iio/temperature/tmp006.c | 8 +++----- > > drivers/iio/temperature/tmp007.c | 8 +++----- > > 60 files changed, 180 insertions(+), 344 deletions(-) > > > > -- > > 2.34.0 > > > >
On Wed, 24 Nov 2021 15:10:06 +0000 Paul Cercueil <paul@crapouillou.net> wrote: > Le mer., nov. 24 2021 at 13:23:47 +0100, Arnd Bergmann <arnd@arndb.de> > a écrit : > > On Wed, Nov 24, 2021 at 11:11 AM Jonathan Cameron > > <Jonathan.Cameron@huawei.com> wrote: > >> On Wed, 24 Nov 2021 08:29:40 +0100 Arnd Bergmann <arnd@arndb.de> > >> 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. Unfortunately since the SET_*_PM_OPS > >> macros are > >> > > used everywhere with code wrapped around #ifdef CONFIG_PM > >> guards, it > >> > > wouldn't be easy to change them, and it would just be easier to > >> > > introduce new macros. > >> > > >> > Right, this is what we've discussed multiple times, and I think > >> everyone > >> > agreed we should do this, but so far we could not come up with a > >> name > >> > for the new macro, and changing the macro in place is not > >> practical unless > >> > we change hundreds of drivers in the same way as the iio series > >> first. > >> > >> Nasty indeed and I'm not sure how scriptable either as lots of > >> subtle variants > >> unfortunately. > > > > The minor variants (late, noirq) are actually the easy part, for the > > macros that > > have fewer users, we can just have one patch per macro that changes > > it treewide. > > For SET_SYSTEM_SLEEP_PM_OPS/SET_RUNTIME_PM_OPS and their > > DEV_PM_OPS variants, this would be a lot harder: > > > > $ for i in SET_SYSTEM_SLEEP_PM_OPS SET_LATE_SYSTEM_SLEEP_PM_OPS > > SET_NOIRQ_SYSTEM_SLEEP_PM_OPS SET_RUNTIME_PM_OPS SIMPLE_DEV_PM_OPS > > UNIVERSAL_DEV_PM_OPS ; do echo `git grep -wl $i | wc -l` $i ; done > > > > 459 SET_SYSTEM_SLEEP_PM_OPS > > 51 SET_LATE_SYSTEM_SLEEP_PM_OPS > > 59 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS > > 497 SET_RUNTIME_PM_OPS > > 797 SIMPLE_DEV_PM_OPS > > 20 UNIVERSAL_DEV_PM_OPS > > > > About half of those actually use an #ifdef, while the other half does > > not: > > > > $ git grep -wl > > 'SET_SYSTEM_SLEEP_PM_OPS\|SET_RUNTIME_PM_OPS\|SIMPLE_DEV_PM_OPS\|UNIVERSAL_DEV_PM_OPS' > > | xargs grep -l CONFIG_PM | wc -l > > 712 > > $ git grep -wl > > 'SET_SYSTEM_SLEEP_PM_OPS\|SET_RUNTIME_PM_OPS\|SIMPLE_DEV_PM_OPS\|UNIVERSAL_DEV_PM_OPS' > > | xargs grep -L CONFIG_PM | wc -l > > 745 > > > > If we rename the macros in the first half of this using a script, > > then we should > > be able to change the behavior of the normal macros to use the new > > pm_ptr(). > > So you want to rename the current macros (to e.g. *_PM_OPS_LEGACY) > everywhere so that new ones can be defined? > > What about we introduce new macros, and just deprecate the old ones > (with e.g. a checkpatch warning)? That would be way less work. Sounds like a sensible approach to me. If Arnd is happy with that we can move forwards and get the bikshedding on the naming started. As ever the true discussion won't start before there is a patch. I'm happy to hold this series for a bit on the basis it'll be simpler without all those __maybe_unused additions, but I don't want to be sitting on it for multiple cycles if it turns out this will take a while to move forwards. Thanks, Jonathan > > -Paul > >
On Sat, Nov 27, 2021 at 7:09 PM Jonathan Cameron <jic23@kernel.org> wrote: > On Wed, 24 Nov 2021 15:10:06 +0000 Paul Cercueil <paul@crapouillou.net> wrote: > > Le mer., nov. 24 2021 at 13:23:47 +0100, Arnd Bergmann <arnd@arndb.de> > > > > So you want to rename the current macros (to e.g. *_PM_OPS_LEGACY) > > everywhere so that new ones can be defined? > > > > What about we introduce new macros, and just deprecate the old ones > > (with e.g. a checkpatch warning)? That would be way less work. > > Sounds like a sensible approach to me. If Arnd is happy with that we > can move forwards and get the bikshedding on the naming started. I suggested renaming the current macros as a way to avoid having to come up with new names. If you have an idea for a new name that makes sense in the long run, please just go ahead with that. Arnd
On Sat, Nov 27, 2021 at 7:02 PM Jonathan Cameron <jic23@kernel.org> wrote: > On Tue, 23 Nov 2021 22:11:08 +0000 Paul Cercueil <paul@crapouillou.net> 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. The only requirement is to use a construct with the ?: operator that gets evaluated at compile time based on CONFIG_PM and CONFIG_PM_SLEEP so that DCE can do its magic. Arnd
Hi, Le dim., nov. 28 2021 at 10:26:40 +0100, Arnd Bergmann <arnd@arndb.de> a écrit : > On Sat, Nov 27, 2021 at 7:02 PM Jonathan Cameron <jic23@kernel.org> > wrote: >> On Tue, 23 Nov 2021 22:11:08 +0000 Paul Cercueil >> <paul@crapouillou.net> 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
Hi Arnd, Jonathan, Le dim., nov. 28 2021 at 10:17:55 +0100, Arnd Bergmann <arnd@arndb.de> a écrit : > On Sat, Nov 27, 2021 at 7:09 PM Jonathan Cameron <jic23@kernel.org> > wrote: >> On Wed, 24 Nov 2021 15:10:06 +0000 Paul Cercueil >> <paul@crapouillou.net> wrote: >> > Le mer., nov. 24 2021 at 13:23:47 +0100, Arnd Bergmann >> <arnd@arndb.de> >> > >> > So you want to rename the current macros (to e.g. *_PM_OPS_LEGACY) >> > everywhere so that new ones can be defined? >> > >> > What about we introduce new macros, and just deprecate the old >> ones >> > (with e.g. a checkpatch warning)? That would be way less work. >> >> Sounds like a sensible approach to me. If Arnd is happy with that we >> can move forwards and get the bikshedding on the naming started. > > I suggested renaming the current macros as a way to avoid having to > come up with new names. If you have an idea for a new name that makes > sense in the long run, please just go ahead with that. Yes, I totally understand that. But renaming such a widespread macro sounds like a huge undertaking... What about: #define SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ .suspend = pm_sleep_ptr(suspend_fn), \ .resume = pm_sleep_ptr(resume_fn), \ ... #ifndef CONFIG_PM_SLEEP #define SET_SYSTEM_SLEEP_PM_OPS(a, b) SYSTEM_SLEEP_PM_OPS(a, b) #else #define SET_SYSTEM_SLEEP_PM_OPS(a, b) #endif #define DEFINE_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ static const struct dev_pm_ops name = { \ SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn), \ } SET_SYSTEM_SLEEP_PM_OPS -> SYSTEM_SLEEP_PM_OPS, with the old one now defined from the new one; SIMPLE_DEV_PM_OPS -> DEFINE_SIMPLE_DEV_PM_OPS. Thoughts? Cheers, -Paul
From: Jonathan Cameron <Jonathan.Cameron@huawei.com> Note this series includes many drivers that are quite old and I'm not sure have active maintainers. Hence if anyone has time to look at some of these beyond their own drivers and sanity check them it would be much appreciated! Two motivations behind this set. 1 - General code reduction and improvement in readability in these drivers. 2 - Reduce change I'll have to ask people to change how they do this in future patches. Mostly this is just a case of letting the compiler work out it can remove the PM related functions rather than using #ifdefs in the code to do so. The __maybe_unused markings make it clear we are intentionally building functions that the compiler can see are unused and remove in some build configurations. The new pm_ptr() macro is rather convenient to got futher than many of the drivers were and when CONFIG_PM is not define ensure that the struct dev_pm_ops can also be removed. Note there is a subtlty in that we only remove that whe CONFIG_PM is not defined whereas a few of these drivers were using CONFIG_PM_SLEEP which is a tighter condition (will remove the structure in more configurations). I think that's a small price to pay for the convenience this macro brings. I did this set as one patch per driver, as personally I prefer that option for all but the most trivial patches because it makes backports that cross with this series simpler and also avoid the complex tag giving we get for sets touching code from many authors. All comments welcome. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Anson Huang <anson.huang@nxp.com> Cc: Brian Masney <masneyb@onstation.org> Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Cc: Icenowy Zheng <icenowy@aosc.io> Cc: Jonathan Albrieux <jonathan.albrieux@gmail.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Luca Weiss <luca@z3ntu.xyz> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Martijn Braam <martijn@brixit.nl> Cc: Maslov Dmitry <maslovdmitry@seeed.cc> Cc: Matt Ranostay <matt.ranostay@konsulko.com Cc: Olivier Moysan <olivier.moysan@foss.st.com> Cc: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com> Cc: Vaishnav M A <vaishnav@beagleboard.org> Jonathan Cameron (49): iio:accel:da311: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:accel:da280: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:accel:dmard06: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:accel:dmard10: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:accel:mc3230: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:accel:mma7660: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:accel:mma9551: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:accel:mma9553: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:accel:stk8ba50: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:accel:kxsd9: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:adc:ab8500: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:adc:ad7606: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:adc:at91-adc: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:adc:exynos_adc: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:adc:palmas_gpadc: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:adc:stm32:Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:adc:rcar: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:adc:rockchip: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:adc:twl6030: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:adc:vf610: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:common:ssp: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:dac:vf610: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:apds9300: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:bh1780: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:light:cm3232: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:isl29018: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:isl29125: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:jsa1212: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:ltr501: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:stk3310: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:tcs3414: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:tcs3472: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:tsl2563: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:tsl4531: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:light:us5182: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:magn:ak8975: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:magn:hmc5843: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:magn:mag3110: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:magn:mmc35240: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:pressure:mpl3115: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:pressure:bmp280: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:proximity:as3935: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:proximity:pulsedlight: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:proximity:rfd77492: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:proximity:sx9500: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:temperature:tmp006: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:temperature:tmp007: Switch from CONFIG_PM_SLEEP guards to pm_ptr() / __maybe_unused iio:gyro:mpu3050: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused iio:chemical:atlas: Switch from CONFIG_PM guards to pm_ptr() / __maybe_unused drivers/iio/accel/da280.c | 6 ++---- drivers/iio/accel/da311.c | 8 +++----- drivers/iio/accel/dmard06.c | 12 ++++-------- drivers/iio/accel/dmard10.c | 9 ++++----- drivers/iio/accel/kxsd9-i2c.c | 2 +- drivers/iio/accel/kxsd9-spi.c | 2 +- drivers/iio/accel/kxsd9.c | 8 +++----- drivers/iio/accel/mc3230.c | 8 +++----- drivers/iio/accel/mma7660.c | 12 +++--------- drivers/iio/accel/mma9551.c | 16 ++++++---------- drivers/iio/accel/mma9553.c | 16 ++++++---------- drivers/iio/accel/stk8ba50.c | 12 +++--------- drivers/iio/adc/ab8500-gpadc.c | 10 ++++------ drivers/iio/adc/ad7606.c | 8 ++------ drivers/iio/adc/ad7606.h | 5 ----- drivers/iio/adc/ad7606_par.c | 2 +- drivers/iio/adc/ad7606_spi.c | 2 +- drivers/iio/adc/at91_adc.c | 8 +++----- drivers/iio/adc/exynos_adc.c | 8 +++----- drivers/iio/adc/palmas_gpadc.c | 14 ++++++-------- drivers/iio/adc/rcar-gyroadc.c | 10 ++++------ drivers/iio/adc/rockchip_saradc.c | 8 +++----- drivers/iio/adc/stm32-adc-core.c | 12 +++++------- drivers/iio/adc/stm32-adc.c | 16 ++++++---------- drivers/iio/adc/twl6030-gpadc.c | 8 +++----- drivers/iio/adc/vf610_adc.c | 8 +++----- drivers/iio/chemical/atlas-sensor.c | 10 ++++------ drivers/iio/common/ssp_sensors/ssp_dev.c | 12 ++++-------- drivers/iio/dac/vf610_dac.c | 8 +++----- drivers/iio/gyro/mpu3050-core.c | 8 +++----- drivers/iio/gyro/mpu3050-i2c.c | 2 +- drivers/iio/light/apds9300.c | 11 +++-------- drivers/iio/light/bh1780.c | 10 ++++------ drivers/iio/light/cm3232.c | 13 ++++--------- drivers/iio/light/isl29018.c | 11 +++-------- drivers/iio/light/isl29125.c | 8 +++----- drivers/iio/light/jsa1212.c | 12 +++--------- drivers/iio/light/ltr501.c | 8 +++----- drivers/iio/light/stk3310.c | 12 +++--------- drivers/iio/light/tcs3414.c | 8 +++----- drivers/iio/light/tcs3472.c | 8 +++----- drivers/iio/light/tsl2563.c | 11 +++-------- drivers/iio/light/tsl4531.c | 11 +++-------- drivers/iio/light/us5182d.c | 10 ++++------ drivers/iio/magnetometer/ak8975.c | 10 ++++------ drivers/iio/magnetometer/hmc5843.h | 5 ----- drivers/iio/magnetometer/hmc5843_i2c.c | 2 +- drivers/iio/magnetometer/hmc5843_spi.c | 2 +- drivers/iio/magnetometer/mag3110.c | 11 +++-------- drivers/iio/magnetometer/mmc35240.c | 12 ++++-------- drivers/iio/pressure/bmp280-core.c | 6 ++---- drivers/iio/pressure/bmp280-i2c.c | 2 +- drivers/iio/pressure/bmp280-spi.c | 2 +- drivers/iio/pressure/mpl3115.c | 11 +++-------- drivers/iio/proximity/as3935.c | 12 +++--------- .../iio/proximity/pulsedlight-lidar-lite-v2.c | 10 ++++------ drivers/iio/proximity/rfd77402.c | 8 +++----- drivers/iio/proximity/sx9500.c | 12 ++++-------- drivers/iio/temperature/tmp006.c | 8 +++----- drivers/iio/temperature/tmp007.c | 8 +++----- 60 files changed, 180 insertions(+), 344 deletions(-)