MIME-Version: 1.0
References: <CANnVG6=a3etRagG+RaSEH-b4_nfzxpEKffQtuMWrttrbgjunZQ@mail.gmail.com>
 <186e23b5668.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
 <CANnVG6kjWj02eEFv_OeLiRtjrJ6yn4EsELz_BtrzFHH15GNMLw@mail.gmail.com>
 <186e26dc0a8.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
 <CANnVG6n-eqKUQnX_6wncmjG1kyVfhxqs2L82xYQpDmGq89eVAQ@mail.gmail.com>
 <186e4673718.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
 <CANnVG6kaGj1SVCqf2y3=Xj_N2G9j+-VhLDN4_WY_ywDswNkO3g@mail.gmail.com>
 <89262772-7358-77e8-8913-c459819d544a@broadcom.com> <a459b9adc5eb7b67a432bd947d47d1df08718762.camel@sipsolutions.net>
 <f430c376-5992-d394-ce55-5994c793c7c7@broadcom.com>
In-Reply-To: <f430c376-5992-d394-ce55-5994c793c7c7@broadcom.com>
From:   Michael Stapelberg <michael+lkml@stapelberg.ch>
Date:   Wed, 15 Mar 2023 20:53:33 +0100
Message-ID: <CANnVG6neOX+Bgc3zWA8k=hwrifmXb=xBN95aMUEyJ=orz3+Wkg@mail.gmail.com>
Subject: Re: wifi breakage due to commit "wifi: brcmfmac: add support for
 vendor-specific firmware api"
To:     Arend van Spriel <arend.vanspriel@broadcom.com>
Cc:     Johannes Berg <johannes@sipsolutions.net>,
        Kalle Valo <kvalo@kernel.org>,
        Franky Lin <franky.lin@broadcom.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>,
        Hante Meuleman <hante.meuleman@broadcom.com>,
        linux-wireless@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hey Arend

Thanks for looking into it.

Your suspicion was spot on: we don=E2=80=99t have /sbin/modprobe (we don=E2=
=80=99t
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/f611656338b68faa5f42bc2c8bbf1e0231a7=
4a50

I=E2=80=99m not entirely sure why I concluded in my earlier testing that
loading the module doesn=E2=80=99t 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 =E2=80=
=94
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=3Dwcc: 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=E2=80=99s
request_module() function
could not find CONFIG_MODPROBE_PATH.

For comparison, when the user space tool exists but fails, including
when it can=E2=80=99t find
the requested module (ENOENT), it always returns exit code 1:
https://salsa.debian.org/md/kmod/-/blob/7d761268ebb68245daf47167e418823c68c=
3eb98/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=E2=80=99m 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 =E2=80=9Cbrcmfmac-wcc=E2=80=9D.

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 firmwa=
re
> >> 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=3D"/sbin/modprobe"
>
> So my suspicion is that modprobe is not at that given location?
>
> Regards,
> Arend