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/[email protected]/
> [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 <[email protected]>
> Signed-off-by: Arend van Spriel <[email protected]>
> ---
> 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/[email protected]/
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 <[email protected]>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216894 [2]
> Reported-by: chainofflowers <[email protected]>
Here you afaics want to add something like this:
Link: https://lore.kernel.org/all/4781984.GXAFRqVoOG@luna/
> Signed-off-by: Arend van Spriel <[email protected]>
> [...]
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.