On March 15, 2023 8:53:50 PM Michael Stapelberg 
<michael+lkml@stapelberg.ch> wrote:

> 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@broadcom.com> 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