Re: [PATCH 00/49] iio: Tree wide switch from CONFIG_PM* to __maybe_unused etc.

From: Jonathan Cameron <jic23@kernel.org>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Anson Huang <anson.huang@nxp.com>,
	Brian Masney <masneyb@onstation.org>,
	Fabrice Gasnier <fabrice.gasnier@foss.st.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Heiko Stuebner <heiko.stuebner@theobroma-systems.com>,
	Icenowy Zheng <icenowy@aosc.io>,
	Jonathan Albrieux <jonathan.albrieux@gmail.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Luca Weiss <luca@z3ntu.xyz>,
	Ludovic Desroches <ludovic.desroches@microchip.com>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Martijn Braam <martijn@brixit.nl>,
	Maslov Dmitry <maslovdmitry@seeed.cc>,
	Olivier Moysan <olivier.moysan@foss.st.com>,
	Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>,
	Vaishnav M A <vaishnav@beagleboard.org>
Subject: Re: [PATCH 00/49] iio: Tree wide switch from CONFIG_PM* to __maybe_unused etc.
Date: Sat, 27 Nov 2021 18:09:23 +0000	[thread overview]
Message-ID: <20211127180923.4cfce721@jic23-huawei> (raw)
In-Reply-To: <US033R.QUSODS2XXA5V3@crapouillou.net>

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