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

[Ping-Ke Shih <pkshih@realtek.com>]

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?

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

Ping-Ke