Re: [PATCH] mmc: sunxi: mark PM functions as __maybe_unused

[Arnd Bergmann]

On Mon, May 28, 2018 at 2:12 PM, Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
> +Cc: Jean
>
> On Mon, May 28, 2018 at 2:13 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> On Mon, May 28, 2018 at 1:04 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>>> On 25 May 2018 at 23:07, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>>> The newly added runtime-pm functions cause a harmless warning
>>>> when CONFIG_PM is disabled:
>>>>
>>>> drivers/mmc/host/sunxi-mmc.c:1452:12: error: 'sunxi_mmc_runtime_suspend' defined but not used [-Werror=unused-function]
>>>>  static int sunxi_mmc_runtime_suspend(struct device *dev)
>>>>             ^~~~~~~~~~~~~~~~~~~~~~~~~
>>>> drivers/mmc/host/sunxi-mmc.c:1435:12: error: 'sunxi_mmc_runtime_resume' defined but not used [-Werror=unused-function]
>>>>  static int sunxi_mmc_runtime_resume(struct device *dev)
>>>>
>>>> This marks them as __maybe_unused to shut up the warning.
>>>
>>> Most mmc drivers uses #ifdef CONFIG_PM instead of the __maybe_unused() option.
>>>
>>> It's not a big deal, but consistency is always good. Would you mind changing?
>>
>> I'd prefer not to. Most uses of #ifdef CONFIG_PM that get introduced are wrong,
>> and cause additional randconfig warnings that I end up having to fix,
>> so I always
>> do it with __maybe_unused.
>
> Some of the maintainers have strong objection against such changes.
> http://lkml.iu.edu/hypermail/linux/kernel/1805.1/06100.html
>
> It seems we might have a split in the opinions, which is not good in
> this case (consistency for PM callbacks overall will be broken).

We actually talked about this at the kernel summit last year, and the conclusion
was that we should replace the SET_RUNTIME_PM_OPS(),
SIMPLE_DEV_PM_OPS(), SET_SYSTEM_SLEEP_PM_OPS()
etc macros with new ones that don't require the ugly #ifdef and just silently
drop the unused functions.

Unfortunately we can't extend the existing macros to work that way (it
breaks for drivers that have an #ifdef today), and nobody could come up
with a new name that is at least as readable as the current one.

Note that incorrect #ifdef usage here is the most common source of
newly introduced build warnings and errors in the kernel, everyone gets
those wrong since they are just very confusing.

       Arnd