Re: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width

[Thorsten Leemhuis <regressions@leemhuis.info>]

On 5/12/26 10:32, Ping-Ke Shih wrote:
> Thorsten Leemhuis <regressions@leemhuis.info> wrote:
>> On 5/12/26 02:44, Ping-Ke Shih wrote:
>>> Thorsten Leemhuis <linux@leemhuis.info> wrote:
>>>> On 5/6/26 09:57, Ping-Ke Shih wrote:
>>>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>>>
>>>>>> Some devices malfunction when connected to a network with 40 MHz channel
>>>>>> width, because they don't support that.
>>>>>>
>>>>>> RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal
>>>>>> this (and some other capabilities) to the driver. Get this information
>>>>>> from the hardware and advertise 40 MHz support only when the hardware
>>>>>> can handle it. We assume the other chips can always handle it.
>>>>>>
>>>>>> RTL8710BU needs a different way to retrieve this information, which will
>>>>>> be implemented some other time.
>>>>>>
>>>>>> Fixes: dbf9b7bb0edf ("wifi: rtl8xxxu: Enable 40 MHz width by default")
>>>>>> Cc: stable@vger.kernel.org
>>>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394
>>>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>>>>>> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
>>>>
>>>> Thx for fixing this!
>>>>
>>>>> 1 patch(es) applied to rtw-next branch of rtw.git, thanks.
>>>>> ef771eabc79d wifi: rtl8xxxu: Detect the maximum supported channel width
>>>>> https://github.com/pkshih/rtw.git
>>>>
>>>> rtw-next sounds like it aims for the next merge window; and it seems the
>>>> fix hasn't even hit -next yet. This is slightly unfortunate, as this
>>>> afaics is a fix for a recent regression -- so it ideally should head
>>>> towards mainline by now[1], as Linus' the rule of thumb is to "generally
>>>> fix regressions "within a week", preferably before the next rc"[1].
>>>>
>>>> Or am I missing something? That might very well be the case, so do not
>>>> hesitate to tell me!
>>>
>>> As this patch applied to public rtw tree, and people who encountered the
>>> problem in bugzilla can work again. To prevent breaking the public tree,
>>> I'd keep it as was.
>> I'm not sure I understand this correctly.
>>
>> Do you mean something like "the fix is now in the rtw-next tree, so I
>> can't mainline it now, as this would break the rtw-next"? But why?
> Yes. (I meant rtw-next tree)
> 
>> You
>> can cherry-pick or directly apply the fix to a pending branch (or even
>> ask Linus to merge it directly from the list, but that is likely not
>> worth it here) and git will normally later notice this and fully
>> automatically handle everything when the fix comes in again during the
>> next merge window.
> 
> I know git can handle that, but is it an acceptable practice for single one
> commit to appear twice?

Depends on whom you ask. I'd say: It's kinda normal. It's best avoided
if there is no need, but if there is a need (like here) it's fine. And
some subsystems it even happens regularly iirc.

> As the reporter has fixed his problem, can we keep this commit as it was?

Well, it boils down to: we don't know how many others are affected that
are unable to bisect and/or report the problem. So usually it's best to
fix things like this for everyone.

Ciao, Thorsten