Hey Arend Thanks for looking into it. Your suspicion was spot on: we don’t have /sbin/modprobe (we don’t even have /sbin!) I addressed this issue by loading the brcmfmac-wcc module where we also load the others: https://github.com/gokrazy/wifi/commit/f611656338b68faa5f42bc2c8bbf1e0231a74a50 I’m not entirely sure why I concluded in my earlier testing that loading the module doesn’t help. Perhaps the issue was that I was manually loading the module after the wifi program tried to use the interface already and had it fail its firmware load — in either case, loading brcmfmac-wcc from the wifi program seems to work fine. I also realize that the error message gives a number of pointers once you know how to interpret it: + brcmfmac: brcmf_fwvid_request_module: mod=wcc: failed -2 I now understand this was trying to tell me that request_module("brcmfmac-wcc") failed with error code -2 (ENOENT), which means that the kernel’s request_module() function could not find CONFIG_MODPROBE_PATH. For comparison, when the user space tool exists but fails, including when it can’t find the requested module (ENOENT), it always returns exit code 1: https://salsa.debian.org/md/kmod/-/blob/7d761268ebb68245daf47167e418823c68c3eb98/tools/modprobe.c#L1025 I think it would be nice if the Linux kernel could print a more descriptive error message in this case. I’m not sure what the kernel conventions are: should the caller of request_module() produce a good error message? Ideally, the message would translate -2 into ENOENT, and mention the name “brcmfmac-wcc”. Or maybe we could have a kconfig option to indicate there is no CONFIG_MODPROBE_PATH, and instead make any request_module() call fail loudly with a descriptive error in dmesg? Thanks for considering Best regards Michael On Wed, 15 Mar 2023 at 11:11, Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote: > > On 3/15/2023 10:57 AM, Johannes Berg wrote: > > On Wed, 2023-03-15 at 10:12 +0100, Arend van Spriel wrote: > >> > >> I think it works pretty similar to firmware loading. These days firmware > >> loading does not rely on a user-space helper and I assumed the same is > >> true for module loading. Will look into it. > >> > > > > As far as I know you still need the modprobe helper in > > > > /proc/sys/kernel/modprobe > > Hi Michael, > > With hint from Johannes I found this Kconfig option: > > config MODPROBE_PATH > string "Path to modprobe binary" > default "/sbin/modprobe" > help > When kernel code requests a module, it does so by calling > the "modprobe" userspace utility. This option allows you to > set the path where that binary is found. This can be changed > at runtime via the sysctl file > /proc/sys/kernel/modprobe. Setting this to the empty string > removes the kernel's ability to request modules (but > userspace can still load modules explicitly). > > Now checking the .config that you sent it says: > > CONFIG_MODPROBE_PATH="/sbin/modprobe" > > So my suspicion is that modprobe is not at that given location? > > Regards, > Arend
