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 was going to say it seems racy, but I am not sure why that works at all. In brcmf_fwvid_request_module it says:
ret = request_module("brcmfmac-%s", fwvid_list[fwvid].name);
if (ret)
goto fail;
and the missing modprobe would always cause request_module() to fail (see
[1]) hence the device probe would fail. What am I missing here?
Regards, Arend [1] https://elixir.bootlin.com/linux/latest/source/kernel/kmod.c#L138
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/modprobeHi 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
