| Message ID | 20230109095020.412475-1-arend.vanspriel@broadcom.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | [for-6.2] wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices | expand |
On 1/9/2023 10:50 AM, Arend van Spriel wrote: > A sanity check was introduced by [1] considering maximum flowrings > above 256 as insane and effectively aborting the device probe. This > resulted in regression for number of users and it is also tracked > in bugzilla [2]. > > [1] https://lore.kernel.org/all/20220929031001.9962-3-ian.lin@infineon.com/ > [2] https://bugzilla.kernel.org/show_bug.cgi?id=216894 > > Fixes: 2aca4f3734bd ("brcmfmac: return error when getting invalid max_flowrings from dongle") > Reported-by: chainofflowers <chainofflowers@posteo.net> > Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > index ae57a9a3ab05..b67f6d0810b6 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > @@ -1228,7 +1228,7 @@ static int brcmf_pcie_init_ringbuffers(struct brcmf_pciedev_info *devinfo) > BRCMF_NROF_H2D_COMMON_MSGRINGS; > max_completionrings = BRCMF_NROF_D2H_COMMON_MSGRINGS; > } > - if (max_flowrings > 256) { > + if (max_flowrings > 512) { This check was added to detect firmware init failure. There should be a better way than using this parameter. For now I decided to simply double the limit to get the regression fixed. > brcmf_err(bus, "invalid max_flowrings(%d)\n", max_flowrings); > return -EIO; > }
On 09.01.23 10:50, Arend van Spriel wrote: > A sanity check was introduced by [1] considering maximum flowrings > above 256 as insane and effectively aborting the device probe. This > resulted in regression for number of users and it is also tracked > in bugzilla [2]. Many thx for taking care of this. There is one small thing to improve to make things easier for future code archaeologists: > [1] https://lore.kernel.org/all/20220929031001.9962-3-ian.lin@infineon.com/ The following line... > [2] https://bugzilla.kernel.org/show_bug.cgi?id=216894 ...should become...: > Fixes: 2aca4f3734bd ("brcmfmac: return error when getting invalid max_flowrings from dongle") ...this instead: Reported-by: Christian Marillat <marillat@debian.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216894 [2] > Reported-by: chainofflowers <chainofflowers@posteo.net> Here you afaics want to add something like this: Link: https://lore.kernel.org/all/4781984.GXAFRqVoOG@luna/ > Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> > [...] To explain: Linus[1] and others considered proper link tags important in cases like this, as they allow anyone to look into the backstory of a fix weeks or years later. That's nothing new, the documentation[2] for some time says to place such tags in cases like this. I care personally (and made it a bit more explicit in the docs a while ago), because these tags make my regression tracking efforts a whole lot easier, as they allow my tracking bot 'regzbot' to automatically connect reports with patches posted or committed to fix tracked regressions. Apropos regzbot, let me tell regzbot to monitor this thread: #regzbot ^backmonitor: https://bugzilla.kernel.org/show_bug.cgi?id=216894 Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) [1] for details, see: https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/ [2] see Documentation/process/submitting-patches.rst (http://docs.kernel.org/process/submitting-patches.html) and Documentation/process/5.Posting.rst (https://docs.kernel.org/process/5.Posting.html) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c index ae57a9a3ab05..b67f6d0810b6 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c @@ -1228,7 +1228,7 @@ static int brcmf_pcie_init_ringbuffers(struct brcmf_pciedev_info *devinfo) BRCMF_NROF_H2D_COMMON_MSGRINGS; max_completionrings = BRCMF_NROF_D2H_COMMON_MSGRINGS; } - if (max_flowrings > 256) { + if (max_flowrings > 512) { brcmf_err(bus, "invalid max_flowrings(%d)\n", max_flowrings); return -EIO; }
A sanity check was introduced by [1] considering maximum flowrings above 256 as insane and effectively aborting the device probe. This resulted in regression for number of users and it is also tracked in bugzilla [2]. [1] https://lore.kernel.org/all/20220929031001.9962-3-ian.lin@infineon.com/ [2] https://bugzilla.kernel.org/show_bug.cgi?id=216894 Fixes: 2aca4f3734bd ("brcmfmac: return error when getting invalid max_flowrings from dongle") Reported-by: chainofflowers <chainofflowers@posteo.net> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)