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

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

[Bitterblue Smith]

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>
---
v2:
 - Rebase on top of rtw-next.
 - Add Reviewed-by.
---
 drivers/net/wireless/realtek/rtl8xxxu/8188e.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/8188f.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/8192c.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/8192e.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/8192f.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/8710b.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/8723a.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/8723b.c |  1 +
 drivers/net/wireless/realtek/rtl8xxxu/core.c  | 64 +++++++++++++++++--
 drivers/net/wireless/realtek/rtl8xxxu/regs.h  |  2 +
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h  |  7 ++
 11 files changed, 76 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8188e.c b/drivers/net/wireless/realtek/rtl8xxxu/8188e.c
index 766a7a7c7d28..fea5aec9ced9 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8188e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8188e.c
@@ -1866,6 +1866,7 @@ struct rtl8xxxu_fileops rtl8188eu_fops = {
 	.has_tx_report = 1,
 	.init_reg_pkt_life_time = 1,
 	.gen2_thermal_meter = 1,
+	.hw_feature_report = 0,
 	.max_sec_cam_num = 32,
 	.adda_1t_init = 0x0b1b25a0,
 	.adda_1t_path_on = 0x0bdb25a0,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8188f.c b/drivers/net/wireless/realtek/rtl8xxxu/8188f.c
index 3abf14d7044f..5556aad1a7ad 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8188f.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8188f.c
@@ -1745,6 +1745,7 @@ struct rtl8xxxu_fileops rtl8188fu_fops = {
 	.init_reg_rxfltmap = 1,
 	.init_reg_pkt_life_time = 1,
 	.init_reg_hmtfr = 1,
+	.hw_feature_report = 1,
 	.ampdu_max_time = 0x70,
 	.ustime_tsf_edca = 0x28,
 	.max_aggr_num = 0x0c14,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8192c.c b/drivers/net/wireless/realtek/rtl8xxxu/8192c.c
index 444872131c66..508322a8f310 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8192c.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8192c.c
@@ -723,6 +723,7 @@ struct rtl8xxxu_fileops rtl8192cu_fops = {
 	.tx_desc_size = sizeof(struct rtl8xxxu_txdesc32),
 	.rx_desc_size = sizeof(struct rtl8xxxu_rxdesc16),
 	.supports_ap = 1,
+	.hw_feature_report = 0,
 	.max_macid_num = 32,
 	.max_sec_cam_num = 32,
 	.adda_1t_init = 0x0b1b25a0,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/8192e.c
index 8e123bbfc665..690ace303150 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8192e.c
@@ -1751,6 +1751,7 @@ struct rtl8xxxu_fileops rtl8192eu_fops = {
 	.has_s0s1 = 0,
 	.gen2_thermal_meter = 1,
 	.needs_full_init = 1,
+	.hw_feature_report = 0,
 	.supports_ap = 1,
 	.max_macid_num = 128,
 	.max_sec_cam_num = 64,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8192f.c b/drivers/net/wireless/realtek/rtl8xxxu/8192f.c
index cd2156b7a57a..5f076da4b550 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8192f.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8192f.c
@@ -2074,6 +2074,7 @@ struct rtl8xxxu_fileops rtl8192fu_fops = {
 	.init_reg_rxfltmap = 1,
 	.init_reg_pkt_life_time = 1,
 	.init_reg_hmtfr = 1,
+	.hw_feature_report = 1,
 	.ampdu_max_time = 0x5e,
 	.ustime_tsf_edca = 0x50,
 	.max_aggr_num = 0x1f1f,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8710b.c b/drivers/net/wireless/realtek/rtl8xxxu/8710b.c
index 11c63c320eae..a87e692bfc81 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8710b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8710b.c
@@ -1852,6 +1852,7 @@ struct rtl8xxxu_fileops rtl8710bu_fops = {
 	.init_reg_rxfltmap = 1,
 	.init_reg_pkt_life_time = 1,
 	.init_reg_hmtfr = 1,
+	.hw_feature_report = 0, /* TODO, it's different */
 	.ampdu_max_time = 0x5e,
 	/*
 	 * The RTL8710BU vendor driver uses 0x50 here and it works fine,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8723a.c b/drivers/net/wireless/realtek/rtl8xxxu/8723a.c
index 4f4493d0bfc2..18e038b82f49 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8723a.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8723a.c
@@ -632,6 +632,7 @@ struct rtl8xxxu_fileops rtl8723au_fops = {
 	.rx_agg_buf_size = 16000,
 	.tx_desc_size = sizeof(struct rtl8xxxu_txdesc32),
 	.rx_desc_size = sizeof(struct rtl8xxxu_rxdesc16),
+	.hw_feature_report = 0,
 	.max_sec_cam_num = 32,
 	.adda_1t_init = 0x0b1b25a0,
 	.adda_1t_path_on = 0x0bdb25a0,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/8723b.c
index cc2e60b06f64..e314ef991b38 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/8723b.c
@@ -1746,6 +1746,7 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
 	.gen2_thermal_meter = 1,
 	.needs_full_init = 1,
 	.init_reg_hmtfr = 1,
+	.hw_feature_report = 0,
 	.ampdu_max_time = 0x5e,
 	.ustime_tsf_edca = 0x50,
 	.max_aggr_num = 0x0c14,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
index 508137e4a87a..646fe76b086e 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
@@ -14,6 +14,7 @@
  */
 
 #include <linux/firmware.h>
+#include <linux/iopoll.h>
 #include "regs.h"
 #include "rtl8xxxu.h"
 
@@ -3915,6 +3916,46 @@ static inline u8 rtl8xxxu_get_macid(struct rtl8xxxu_priv *priv,
 	return sta_info->macid;
 }
 
+static void rtl8xxxu_request_hw_feature(struct rtl8xxxu_priv *priv)
+{
+	if (!priv->fops->hw_feature_report)
+		return;
+
+	rtl8xxxu_write8(priv, REG_C2HEVT_MSG_NORMAL, C2H_HW_FEATURE_DUMP);
+}
+
+static int rtl8xxxu_dump_hw_feature(struct rtl8xxxu_priv *priv)
+{
+	static const u8 bw_map[8] = { 0, 0, 160, 5, 10, 20, 40, 80 };
+	struct rtl8xxxu_hw_feature *hw_feature = &priv->hw_feature;
+	u8 feature[13];
+	int i, ret;
+	u8 id, bw;
+
+	if (!priv->fops->hw_feature_report) {
+		hw_feature->max_bw = 40;
+		return 0;
+	}
+
+	ret = read_poll_timeout(rtl8xxxu_read8, id,
+				id == C2H_HW_FEATURE_REPORT,
+				10000, 800000, false,
+				priv, REG_C2HEVT_MSG_NORMAL);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < ARRAY_SIZE(feature); i++)
+		feature[i] = rtl8xxxu_read8(priv, REG_C2HEVT_MSG_NORMAL + 2 + i);
+
+	rtl8xxxu_write8(priv, REG_C2HEVT_MSG_NORMAL, 0);
+
+	bw = u8_get_bits(feature[6], GENMASK(2, 0));
+
+	hw_feature->max_bw = bw_map[bw];
+
+	return 0;
+}
+
 static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
 {
 	struct rtl8xxxu_priv *priv = hw->priv;
@@ -3961,6 +4002,8 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
 	 */
 	rtl8xxxu_write16(priv, REG_TRXFF_BNDY + 2, fops->trxff_boundary);
 
+	rtl8xxxu_request_hw_feature(priv);
+
 	for (int retry = 5; retry >= 0 ; retry--) {
 		ret = rtl8xxxu_download_firmware(priv);
 		dev_dbg(dev, "%s: download_firmware %i\n", __func__, ret);
@@ -3976,6 +4019,12 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
 	if (ret)
 		goto exit;
 
+	ret = rtl8xxxu_dump_hw_feature(priv);
+	if (ret) {
+		dev_err(dev, "failed to dump hw feature\n");
+		goto exit;
+	}
+
 	if (fops->phy_init_antenna_selection)
 		fops->phy_init_antenna_selection(priv);
 
@@ -7844,15 +7893,20 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
 	sband->ht_cap.ht_supported = true;
 	sband->ht_cap.ampdu_factor = IEEE80211_HT_MAX_AMPDU_64K;
 	sband->ht_cap.ampdu_density = IEEE80211_HT_MPDU_DENSITY_16;
-	sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40 |
-			    IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+	sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20;
+
+	if (priv->hw_feature.max_bw >= 40) {
+		sband->ht_cap.cap |= IEEE80211_HT_CAP_SGI_40;
+		sband->ht_cap.cap |= IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+	} else {
+		dev_info(&udev->dev, "hardware doesn't support HT40\n");
+	}
+
 	memset(&sband->ht_cap.mcs, 0, sizeof(sband->ht_cap.mcs));
 	sband->ht_cap.mcs.rx_mask[0] = 0xff;
 	sband->ht_cap.mcs.rx_mask[4] = 0x01;
-	if (priv->rf_paths > 1) {
+	if (priv->rf_paths > 1)
 		sband->ht_cap.mcs.rx_mask[1] = 0xff;
-		sband->ht_cap.cap |= IEEE80211_HT_CAP_SGI_40;
-	}
 	sband->ht_cap.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
 
 	hw->wiphy->bands[NL80211_BAND_2GHZ] = sband;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/regs.h b/drivers/net/wireless/realtek/rtl8xxxu/regs.h
index 0741db8d08bf..eafaef1438b9 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/regs.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/regs.h
@@ -447,6 +447,8 @@
 /* 8188EU */
 #define REG_32K_CTRL			0x0194
 #define REG_C2HEVT_MSG_NORMAL		0x01a0
+#define C2H_HW_FEATURE_REPORT		0x19
+#define C2H_HW_FEATURE_DUMP		0xfd
 /* 8192EU/8723BU/8812 */
 #define REG_C2HEVT_CMD_ID_8723B		0x01ae
 #define REG_C2HEVT_CLEAR		0x01af
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 9fb2583ffffc..eeb18eb0e4c0 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1789,11 +1789,17 @@ struct rtl8xxxu_cfo_tracking {
 #define RTL8XXXU_BC_MC_MACID1	1
 #define RTL8XXXU_MAX_SEC_CAM_NUM	64
 
+struct rtl8xxxu_hw_feature {
+	u8 max_bw;
+};
+
 struct rtl8xxxu_priv {
 	struct ieee80211_hw *hw;
 	struct usb_device *udev;
 	struct rtl8xxxu_fileops *fops;
 
+	struct rtl8xxxu_hw_feature hw_feature;
+
 	spinlock_t tx_urb_lock;
 	struct list_head tx_urb_free_list;
 	int tx_urb_free_count;
@@ -2009,6 +2015,7 @@ struct rtl8xxxu_fileops {
 	u8 init_reg_pkt_life_time:1;
 	u8 init_reg_hmtfr:1;
 	u8 supports_concurrent:1;
+	u8 hw_feature_report:1;
 	u8 ampdu_max_time;
 	u8 ustime_tsf_edca;
 	u16 max_aggr_num;
-- 
2.53.0

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

[Ping-Ke Shih]

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>

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

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

[Thorsten Leemhuis]

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!

Ciao, Thorsten

[1]
https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed

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

[Ping-Ke Shih]

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 will be carefully to handle this kind of patches later. 

Ping-Ke

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

[Thorsten Leemhuis]

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? 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.

Or did I misinterpret what you meant?

Ciao, Thorsten

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

[Ping-Ke Shih]

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

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

[Thorsten Leemhuis]

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

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

[Johannes Berg]

On Tue, 2026-05-12 at 10:54 +0200, Thorsten Leemhuis wrote:
> > > 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.

FWIW, it's generally frowned upon and actually uncommon enough that
linux-next actively warns about it [1] (or at least used to?), so I
wouldn't really say your description here is all that accurate.

[1] https://lore.kernel.org/lkml/?q=%22duplicate+patch+in+the%22

What does happen fairly frequently is the same immutable commit getting
merged through different branches, but that's a single commit, not the
same change being committed twice.

johannes

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

[Thorsten Leemhuis]

On 5/12/26 11:36, Johannes Berg wrote:
> On Tue, 2026-05-12 at 10:54 +0200, Thorsten Leemhuis wrote:
>>>> 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.
> > FWIW, it's generally frowned upon and actually uncommon enough that
> linux-next actively warns about it [1] (or at least used to?), so I
> wouldn't really say your description here is all that accurate.
>
> [1] https://lore.kernel.org/lkml/?q=%22duplicate+patch+in+the%22
> 
> What does happen fairly frequently is the same immutable commit getting
> merged through different branches, but that's a single commit, not the
> same change being committed twice.

Well, that made me look up my "regularly iirc" claim. Now I remember
where I got that from: the cherry-picking (which results in a second
commit-id) the DRM subsystem regularly did:
https://lwn.net/Articles/1005222/

That's was early 2025, so the workflows there might have changed in
between due to the criticism. But from a quick 'git log --grep "(cherry
picked from commit"' in mainline it doesn't look like it did. Here is
one example of a commit that made it into 7.0 that sits with a different
commit-id in -next a second time:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=Avoid+memory+allocations+in+xe_device_declare_wedged
b08ceb44386680 ("drm/xe: Avoid memory allocations in
xe_device_declare_wedged()") [next-20260330]
56b7432b7e8e6a ("drm/xe: Avoid memory allocations in
xe_device_declare_wedged()") [v7.0-rc7]

Here are a few from the current cycle:

0d831487b5be0a ("drm/amdgpu: nuke amdgpu_userq_fence_slab v2")
[next-20260506]
4e02e0afa95f69 ("drm/amdgpu: nuke amdgpu_userq_fence_slab v2") [v7.1-rc3]
1fc6c8ab45dbee ("drm/amdgpu/userq: fix access to stale wptr mapping")
[next-20260506]
6da7b1242da445 ("drm/amdgpu/userq: fix access to stale wptr mapping")
[v7.1-rc3]
d12d05c4bc4c15 ("drm/amdkfd: Check if there are kfd porcesses using adev
by kfd_processes_count") [next-20260506]
81665e35f143d9 ("drm/amdkfd: Check if there are kfd porcesses using adev
by kfd_processes_count") [v7.1-rc3]
d9af8263b82b6e ("drm/amdgpu: zero-initialize GART table on allocation")
[next-20260506]
e6c2e6c2e1fa06 ("drm/amdgpu: zero-initialize GART table on allocation")
[v7.1-rc3]

I found a few dozen more. But this is not my area of expertise, so
please correct me if I'm missing something.

In the end I don't care about all that. I just think it would be good to
get this regression fixed in mainline this cycle. And I suspect Linus
wants that, too. For example due to previous discussions like this:
https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/

Ciao, Thorsten