On 12/27/24 10:20 AM, Geert Uytterhoeven wrote: > Hi Al, > > On Fri, Dec 27, 2024 at 5:22 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
