Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <097cb5d3-2756-ad48-bdc2-fef733776387@leemhuis.info>
Date:   Mon, 9 Jan 2023 11:09:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH for-6.2] wifi: brcmfmac: fix regression for Broadcom PCIe
 wifi devices
Content-Language: en-US, de-DE
To:     Arend van Spriel <arend.vanspriel@broadcom.com>,
        Kalle Valo <kvalo@kernel.org>
Cc:     linux-wireless@vger.kernel.org,
        chainofflowers <chainofflowers@posteo.net>
References: <20230109095020.412475-1-arend.vanspriel@broadcom.com>
From:   "Linux kernel regression tracking (Thorsten Leemhuis)" 
        <regressions@leemhuis.info>
Reply-To: Linux regressions mailing list <regressions@lists.linux.dev>
In-Reply-To: <20230109095020.412475-1-arend.vanspriel@broadcom.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.