Re: [PATCH v2 01/51] iio:accel:da311: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc

[Paul Cercueil <paul@crapouillou.net>]

Hi,

Le mar., janv. 4 2022 at 14:16:01 +0000, Jonathan Cameron 
<Jonathan.Cameron@Huawei.com> a écrit :
> On Mon, 3 Jan 2022 12:58:46 -0500
> Arnd Bergmann <arnd@arndb.de> wrote:
> 
>>  On Mon, Jan 3, 2022 at 10:24 AM Jonathan Cameron <jic23@kernel.org> 
>> wrote:
>>  > On Sun, 2 Jan 2022 09:15:06 -0500 Arnd Bergmann <arnd@arndb.de> 
>> wrote:
>>  >
>>  > That came up in discussion of the patch series introducing this 
>> macro
>>  > 
>> https://lore.kernel.org/linux-pm/20211216110936.6ccd07d3@jic23-huawei/
>>  >
>>  > Most of the cases that don't define it as static
>>  > also export the symbol for use by other modules so the approach 
>> of letting
>>  > the compiler detect it as dead code won't always work.
>>  >
>>  > Exceptions from a bit of grepping are
>>  > net/ethernet/broadcom/bnx2x/
>>  > scsi/esas2r/esas2r_init.c
>>  >   not sure on reasoning behind the file splits in these drivers
>>  >   but definitely looks like it we could just merge a few files
>>  >   and let this be static + the compiler remove it neatly.
>>  >
>>  > vs 17 cases where the symbol is exported and more cleverness will
>>  > be needed.
>> 
>>  I don't see why exporting the symbol makes a difference at all, 
>> either
>>  it is needed in another file or it is not.
> 
> Ah. My reasoning was that the purpose behind that patch set (letting
> compiler remove the functions etc when unused) was not applicable in 
> EXPORT*
> cases.  However, I'd neglected that the DEFINE_SIMPLE_DEV_PM_OPS()
> macro is probably useful anyway as those cases would need CONFIG_PM*
> guards if they want to remove the code when PM stuff isn't enabled.
> 
>> 
>>  I think it would be more natural to not include 'static' in the 
>> macro,
>>  that is certainly what all other macros like this do, and it's still
>>  trivial to add 'static' manually, but impossible to remove it.
> 
> IIRC there are other cases like this, but it was exactly this somewhat
> unusual element that made me raise the question in the original 
> discussion.
> 
> Paul, over to you for reasoning.  If we are going to change this
> now is the time before they get significant use and we end up having
> to add static to lots of places.

I have an idea on how to tackle automatic dead code removal on exported 
dev_pm_ops symbols. It means introducing a separate 
EXPORTED_SIMPLE_DEV_PM_OPS(), so the current DEFINE_SIMPLE_DEV_PM_OPS() 
macro could keep the "static". Unless you still think it's a bad idea, 
then in this case we can remove it.

Cheers,
-Paul