Re: [PATCH v2 1/6] mmc: sdhci: Use EXPORT_PM_FN_NS_GPL() for exporting PM functions

[Richard Fitzgerald <rf@opensource.cirrus.com>]

On 16/01/2025 3:14 pm, Andy Shevchenko wrote:
> On Mon, Dec 09, 2024 at 07:11:41PM +0200, Adrian Hunter wrote:
>> On 9/12/24 18:36, Andy Shevchenko wrote:
>>> On Mon, Dec 09, 2024 at 12:38:59PM +0200, Adrian Hunter wrote:
>>>> On 1/11/24 12:11, Andy Shevchenko wrote:
>>>>> Switch from ugly ifdeffery to using EXPORT_PM_FN_NS_GPL()
>>>>> for exporting PM functions. This helps cleaning up the other
>>>>> SDHCI drivers in the future.
>>>>
>>>> It seems sdhci is the first code in the kernel to use
>>>> EXPORT_PM_FN_NS_GPL() but it was not asked for ;-)
>>>>
>>>> As such, can you fill in a little background.  I am not
>>>> sure what it achieves.  Why have CONFIG_PM if not to
>>>> #ifdef dependent code behind it?
>>>
>>> It makes sure that the code elimination happens at compile time and
>>
>> Does it eliminate the code?  Maybe I am missing something,
>> but it looks like it is still there:
> 
> Hmm... Indeed. My tests show the same. I believe these new macros were never
> tested (and we have no users in the kernel).
> 
> Richard?
> 

As I recall the intention wasn't to eliminate the code. It was to
eliminate the EXPORT for code that had already been eliminated by other
macros.

A bunch of ugly macros were added a while back by someone to create PM
callback functions so that the code would be eliminated if CONFIG_PM=n,
without having to use __maybe_unused or ifdefs in the .c, And together
with this, drivers were being zealously changed to use these macros to
eliminated unused PM callbacks.

But the macros assumed the PM functions were always local static.
Sometimes a family of drivers for similar hardware share common code and
the PM functions are exported so I added these macros to make the EXPORT
also disappear. It's not great but it was based on an existing similar
pattern.

I did also have patches that used the macros with the PM wrapper macros
to eliminate the code and exports in the cs35l56 codec driver. But they
got held up behind a large backlog of other work and are basically still
sitting in a dark corner somewhere. At this point it doesn't seem worth
the trouble to eliminate the PM callbacks, especially as we don't know
of any platform that is using codecs like cs35l56 without PM. So really
I don't mind if you remove these EXPORT macros.

>>> at the same time gives developer less uglified (by ifdeffery) code.
>>> It means there is less risk to miss anything of that which make become
>>> a compile-time warning of unused function, or even issues during linking
>>> with modules, etc.
>>>
>>> Should I update a commit message with that?
>