Re: [PATCH] sh: exports for delay.h

On 12/27/24 10:20 AM, Geert Uytterhoeven wrote:
> Hi Al,
> 
> On Fri, Dec 27, 2024 at 5:22 PM Al Viro <[email protected]> wrote:
>> On Fri, Dec 27, 2024 at 04:58:58PM +0100, Geert Uytterhoeven wrote:
>>> Please do not export __delay, as it is an internal implementation detail.
>>> Drivers should not call __delay() directly, as it has non-standardized
>>> semantics, or may not even exist.
>>
>> As the matter of fact, it *does* exist and is either exported or a static
>> inline with everything used by it exported - on every architecture except sh.
> 
> OK, it does exist, because init/calibrate.c needs it. But that should
> be the sole user outside architecture-specific code.
> 
> Unlike some other architectures, SH does not emit calls to __delay()
> from various (static inline) *delay() functions.  Hence there is no
> need to export it to modules. Heck, the only reason it cannot be made
> static is because init/calibrate.c needs it.
> 
> Unfortunately there are still a few drivers that call __delay()
> directly (usually with hardcoded constants, how portable, and
> cpufreq-unfriendly), which causes people to try once in a while to
> "fix the build" by re-adding the export on SH :-(

Yeah, I did that in 2021 because of:

ERROR: modpost: "__delay" [drivers/net/mdio/mdio-cavium.ko] undefined!

mdio-cavium still uses __delay() so I guess it still breaks an SH build.

-- 
~Randy