[PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Luka Gejak]

USB decides in usb.c which broadcast and multicast (bmc) frames may use
the high queue. SDIO needs the same decision, so move the helpers to
tx.c behind a single exported rtw_tx_bmc_use_hiq() and keep the budget
state in struct rtw_dev.

No functional change.

Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
 drivers/net/wireless/realtek/rtw88/main.c |  3 ++
 drivers/net/wireless/realtek/rtw88/main.h |  5 ++
 drivers/net/wireless/realtek/rtw88/tx.c   | 59 +++++++++++++++++++++
 drivers/net/wireless/realtek/rtw88/tx.h   |  4 ++
 drivers/net/wireless/realtek/rtw88/usb.c  | 64 ++---------------------
 drivers/net/wireless/realtek/rtw88/usb.h  |  5 --
 6 files changed, 74 insertions(+), 66 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 0f23498b5c96..b72173964bdd 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -2177,6 +2177,9 @@ int rtw_core_init(struct rtw_dev *rtwdev)
 
 	spin_lock_init(&rtwdev->txq_lock);
 	spin_lock_init(&rtwdev->tx_report.q_lock);
+	spin_lock_init(&rtwdev->hiq_lock);
+	rtwdev->hiq_budget = RTW_TX_HIQ_BUDGET_MAX;
+	rtwdev->hiq_refill = jiffies;
 
 	mutex_init(&rtwdev->mutex);
 	mutex_init(&rtwdev->hal.tx_power_mutex);
diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
index d59f6e323adf..c14c834c27fd 100644
--- a/drivers/net/wireless/realtek/rtw88/main.h
+++ b/drivers/net/wireless/realtek/rtw88/main.h
@@ -2104,6 +2104,11 @@ struct rtw_dev {
 
 	struct rtw_tx_report tx_report;
 
+	/* protects hiq_budget and hiq_refill */
+	spinlock_t hiq_lock;
+	u32 hiq_budget;
+	unsigned long hiq_refill;
+
 	struct {
 		/* indicate the mail box to use with fw */
 		u8 last_box_num;
diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
index 701ed7c4f3f7..82c1af94f1cc 100644
--- a/drivers/net/wireless/realtek/rtw88/tx.c
+++ b/drivers/net/wireless/realtek/rtw88/tx.c
@@ -2,6 +2,8 @@
 /* Copyright(c) 2018-2019  Realtek Corporation
  */
 
+#include <linux/ip.h>
+#include <linux/udp.h>
 #include "main.h"
 #include "tx.h"
 #include "fw.h"
@@ -745,3 +747,60 @@ enum rtw_tx_queue_type rtw_tx_queue_mapping(struct sk_buff *skb)
 	return queue;
 }
 EXPORT_SYMBOL(rtw_tx_queue_mapping);
+
+static bool rtw_tx_bmc_needs_dtim(struct sk_buff *skb)
+{
+	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+	struct udphdr *udphdr;
+
+	if (info->control.flags & IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
+		return true;
+
+	if (skb->protocol == htons(ETH_P_ARP))
+		return true;
+
+	if (skb->protocol == htons(ETH_P_IP) &&
+	    ip_hdr(skb)->protocol == IPPROTO_UDP) {
+		udphdr = udp_hdr(skb);
+
+		return udphdr->dest == htons(67) || udphdr->dest == htons(68);
+	}
+
+	return false;
+}
+
+static bool rtw_tx_hiq_take_budget(struct rtw_dev *rtwdev)
+{
+	unsigned long flags, elapsed, add;
+	bool ok;
+
+	spin_lock_irqsave(&rtwdev->hiq_lock, flags);
+
+	elapsed = jiffies - rtwdev->hiq_refill;
+	add = elapsed / RTW_TX_HIQ_REFILL_INTERVAL;
+	if (add) {
+		rtwdev->hiq_budget = min_t(unsigned long, rtwdev->hiq_budget + add,
+					   RTW_TX_HIQ_BUDGET_MAX);
+
+		/* keep the unfinished part of the interval for the next unit */
+		rtwdev->hiq_refill = jiffies - elapsed % RTW_TX_HIQ_REFILL_INTERVAL;
+	}
+
+	ok = rtwdev->hiq_budget > 0;
+	if (ok)
+		rtwdev->hiq_budget--;
+
+	spin_unlock_irqrestore(&rtwdev->hiq_lock, flags);
+
+	return ok;
+}
+
+bool rtw_tx_bmc_use_hiq(struct rtw_dev *rtwdev, struct sk_buff *skb)
+{
+	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+
+	return (info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) &&
+	       rtw_tx_bmc_needs_dtim(skb) &&
+	       rtw_tx_hiq_take_budget(rtwdev);
+}
+EXPORT_SYMBOL(rtw_tx_bmc_use_hiq);
diff --git a/drivers/net/wireless/realtek/rtw88/tx.h b/drivers/net/wireless/realtek/rtw88/tx.h
index 168f48e87853..a68ba3b12159 100644
--- a/drivers/net/wireless/realtek/rtw88/tx.h
+++ b/drivers/net/wireless/realtek/rtw88/tx.h
@@ -10,6 +10,9 @@
 #define RTW_TX_PROBE_TIMEOUT_SHORT	msecs_to_jiffies(500)
 #define RTW_TX_PROBE_TIMEOUT_LONG	msecs_to_jiffies(2500)
 
+#define RTW_TX_HIQ_REFILL_INTERVAL	(HZ / 10)
+#define RTW_TX_HIQ_BUDGET_MAX		16
+
 struct rtw_tx_desc {
 	__le32 w0;
 	__le32 w1;
@@ -115,6 +118,7 @@ rtw_tx_write_data_h2c_get(struct rtw_dev *rtwdev,
 
 enum rtw_tx_queue_type rtw_tx_ac_to_hwq(enum ieee80211_ac_numbers ac);
 enum rtw_tx_queue_type rtw_tx_queue_mapping(struct sk_buff *skb);
+bool rtw_tx_bmc_use_hiq(struct rtw_dev *rtwdev, struct sk_buff *skb);
 
 static inline
 void fill_txdesc_checksum_common(u8 *txdesc, size_t words)
diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
index 715a2ce342d9..13adbd415158 100644
--- a/drivers/net/wireless/realtek/rtw88/usb.c
+++ b/drivers/net/wireless/realtek/rtw88/usb.c
@@ -2,10 +2,8 @@
 /* Copyright(c) 2018-2019  Realtek Corporation
  */
 
-#include <linux/ip.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
-#include <linux/udp.h>
 #include <linux/usb.h>
 #include "main.h"
 #include "debug.h"
@@ -564,61 +562,10 @@ static int rtw_usb_write_data_h2c(struct rtw_dev *rtwdev, u8 *buf, u32 size)
 	return rtw_usb_write_data(rtwdev, &pkt_info, buf);
 }
 
-static bool rtw_usb_bmc_needs_dtim(struct sk_buff *skb)
-{
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
-	struct udphdr *udphdr;
-
-	if (info->control.flags & IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
-		return true;
-
-	if (skb->protocol == htons(ETH_P_ARP))
-		return true;
-
-	if (skb->protocol == htons(ETH_P_IP) &&
-	    ip_hdr(skb)->protocol == IPPROTO_UDP) {
-		udphdr = udp_hdr(skb);
-
-		return udphdr->dest == htons(67) || udphdr->dest == htons(68);
-	}
-
-	return false;
-}
-
-#define RTW_USB_HIQ_REFILL_INTERVAL	(HZ / 10)	/* one unit of budget per 100 ms */
-#define RTW_USB_HIQ_BUDGET_MAX		16
-
-static bool rtw_usb_hiq_take_budget(struct rtw_usb *rtwusb)
-{
-	unsigned long flags, elapsed, add;
-	bool ok;
-
-	spin_lock_irqsave(&rtwusb->hiq_lock, flags);
-
-	elapsed = jiffies - rtwusb->hiq_refill;
-	add = elapsed / RTW_USB_HIQ_REFILL_INTERVAL;
-	if (add) {
-		rtwusb->hiq_budget = min_t(unsigned long, rtwusb->hiq_budget + add,
-					   RTW_USB_HIQ_BUDGET_MAX);
-
-		/* keep the unfinished part of the interval for the next unit */
-		rtwusb->hiq_refill = jiffies - elapsed % RTW_USB_HIQ_REFILL_INTERVAL;
-	}
-
-	ok = rtwusb->hiq_budget > 0;
-	if (ok)
-		rtwusb->hiq_budget--;
-
-	spin_unlock_irqrestore(&rtwusb->hiq_lock, flags);
-
-	return ok;
-}
-
-static u8 rtw_usb_tx_queue_mapping_to_qsel(struct rtw_usb *rtwusb,
+static u8 rtw_usb_tx_queue_mapping_to_qsel(struct rtw_dev *rtwdev,
 					   struct sk_buff *skb)
 {
 	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	__le16 fc = hdr->frame_control;
 	u8 qsel;
 
@@ -626,8 +573,7 @@ static u8 rtw_usb_tx_queue_mapping_to_qsel(struct rtw_usb *rtwusb,
 		qsel = TX_DESC_QSEL_MGMT;
 	else if (is_broadcast_ether_addr(hdr->addr1) ||
 		 is_multicast_ether_addr(hdr->addr1))
-		qsel = (info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) &&
-		       rtw_usb_bmc_needs_dtim(skb) && rtw_usb_hiq_take_budget(rtwusb) ?
+		qsel = rtw_tx_bmc_use_hiq(rtwdev, skb) ?
 		       TX_DESC_QSEL_HIGH : skb->priority;
 	else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK)
 		qsel = skb->priority;
@@ -647,7 +593,7 @@ static int rtw_usb_tx_write(struct rtw_dev *rtwdev,
 	u8 *pkt_desc;
 	int ep;
 
-	pkt_info->qsel = rtw_usb_tx_queue_mapping_to_qsel(rtwusb, skb);
+	pkt_info->qsel = rtw_usb_tx_queue_mapping_to_qsel(rtwdev, skb);
 	pkt_desc = skb_push(skb, chip->tx_pkt_desc_sz);
 	memset(pkt_desc, 0, chip->tx_pkt_desc_sz);
 	ep = qsel_to_ep(rtwusb, pkt_info->qsel);
@@ -1088,10 +1034,6 @@ static int rtw_usb_init_tx(struct rtw_dev *rtwdev)
 	struct rtw_usb *rtwusb = rtw_get_usb_priv(rtwdev);
 	int i;
 
-	spin_lock_init(&rtwusb->hiq_lock);
-	rtwusb->hiq_budget = RTW_USB_HIQ_BUDGET_MAX;
-	rtwusb->hiq_refill = jiffies;
-
 	rtwusb->txwq = create_singlethread_workqueue("rtw88_usb: tx wq");
 	if (!rtwusb->txwq) {
 		rtw_err(rtwdev, "failed to create TX work queue\n");
diff --git a/drivers/net/wireless/realtek/rtw88/usb.h b/drivers/net/wireless/realtek/rtw88/usb.h
index 94ff21dd0846..9b695b688b24 100644
--- a/drivers/net/wireless/realtek/rtw88/usb.h
+++ b/drivers/net/wireless/realtek/rtw88/usb.h
@@ -75,11 +75,6 @@ struct rtw_usb {
 	u8 out_ep[RTW_USB_EP_MAX];
 	int qsel_to_ep[TX_DESC_QSEL_MAX];
 
-	/* protects hiq_budget and hiq_refill */
-	spinlock_t hiq_lock;
-	u32 hiq_budget;
-	unsigned long hiq_refill;
-
 	struct workqueue_struct *txwq, *rxwq;
 
 	struct sk_buff_head tx_queue[RTW_USB_EP_MAX];
-- 
2.53.0

[PATCH rtw-next v2 2/2] wifi: rtw88: sdio: limit the high queue to DTIM delivery

[Luka Gejak]

In AP mode every broadcast and multicast (bmc) frame is sent through the
high queue, which the hardware only drains after a DTIM beacon. Only a
few frames leave per DTIM, so steady multicast traffic builds a backlog
that holds the TX pages the other queues need. Unicast traffic then
stalls for seconds and clients can no longer renew their DHCP lease.

USB had the same problem and was fixed by commit c710c7c2e038 ("wifi:
rtw88: usb: route bmc frames via the high queue only for DTIM delivery")
and the two commits that followed it. Use the same rule for SDIO. A bmc
frame goes to the high queue only when mac80211 asks for DTIM delivery
because a station is dozing, the frame is ARP, EAPOL or DHCP, and the
budget allows it. All other bmc frames go out on their access category
queue.

Tested on RTL8723BS with an ath9k client.

Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
 drivers/net/wireless/realtek/rtw88/sdio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
index dc2fd0f8f9ff..83e9b301ae9b 100644
--- a/drivers/net/wireless/realtek/rtw88/sdio.c
+++ b/drivers/net/wireless/realtek/rtw88/sdio.c
@@ -1308,6 +1308,9 @@ static int rtw_sdio_tx_write(struct rtw_dev *rtwdev,
 	u16 q_map = skb_get_queue_mapping(skb);
 	struct rtw_sdio_tx_data *tx_data;
 
+	if (queue == RTW_TX_QUEUE_HI0 && !rtw_tx_bmc_use_hiq(rtwdev, skb))
+		queue = rtw_tx_ac_to_hwq(q_map);
+
 	rtw_sdio_tx_skb_prepare(rtwdev, pkt_info, skb, queue);
 
 	tx_data = rtw_sdio_get_tx_data(skb);
-- 
2.53.0

RE: [PATCH rtw-next v2 2/2] wifi: rtw88: sdio: limit the high queue to DTIM delivery

[Ping-Ke Shih]

Luka Gejak <luka.gejak@linux.dev> wrote:
> In AP mode every broadcast and multicast (bmc) frame is sent through the
> high queue, which the hardware only drains after a DTIM beacon. Only a
> few frames leave per DTIM, so steady multicast traffic builds a backlog
> that holds the TX pages the other queues need. Unicast traffic then
> stalls for seconds and clients can no longer renew their DHCP lease.
> 
> USB had the same problem and was fixed by commit c710c7c2e038 ("wifi:
> rtw88: usb: route bmc frames via the high queue only for DTIM delivery")
> and the two commits that followed it. Use the same rule for SDIO. A bmc
> frame goes to the high queue only when mac80211 asks for DTIM delivery
> because a station is dozing, the frame is ARP, EAPOL or DHCP, and the
> budget allows it. All other bmc frames go out on their access category
> queue.

I'd remove second paragraph since it just describes the patch 1/2 does. 

> 
> Tested on RTL8723BS with an ath9k client.
> 
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

Re: [PATCH rtw-next v2 2/2] wifi: rtw88: sdio: limit the high queue to DTIM delivery

[Luka Gejak]

October 22, 2026 at 4:24 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:


> 
> Luka Gejak <luka.gejak@linux.dev> wrote:
> 
> > 
> > In AP mode every broadcast and multicast (bmc) frame is sent through the
> >  high queue, which the hardware only drains after a DTIM beacon. Only a
> >  few frames leave per DTIM, so steady multicast traffic builds a backlog
> >  that holds the TX pages the other queues need. Unicast traffic then
> >  stalls for seconds and clients can no longer renew their DHCP lease.
> >  
> >  USB had the same problem and was fixed by commit c710c7c2e038 ("wifi:
> >  rtw88: usb: route bmc frames via the high queue only for DTIM delivery")
> >  and the two commits that followed it. Use the same rule for SDIO. A bmc
> >  frame goes to the high queue only when mac80211 asks for DTIM delivery
> >  because a station is dozing, the frame is ARP, EAPOL or DHCP, and the
> >  budget allows it. All other bmc frames go out on their access category
> >  queue.
> > 
> I'd remove second paragraph since it just describes the patch 1/2 does. 
> 

Would you be willing to drop it your when applying?

Best regards,
Luka Gejak

RE: [PATCH rtw-next v2 2/2] wifi: rtw88: sdio: limit the high queue to DTIM delivery

[Ping-Ke Shih]

Luka Gejak <luka.gejak@linux.dev> wrote:
> October 22, 2026 at 4:24 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:
> 
> 
> >
> > Luka Gejak <luka.gejak@linux.dev> wrote:
> >
> > >
> > > In AP mode every broadcast and multicast (bmc) frame is sent through the
> > >  high queue, which the hardware only drains after a DTIM beacon. Only a
> > >  few frames leave per DTIM, so steady multicast traffic builds a backlog
> > >  that holds the TX pages the other queues need. Unicast traffic then
> > >  stalls for seconds and clients can no longer renew their DHCP lease.
> > >
> > >  USB had the same problem and was fixed by commit c710c7c2e038 ("wifi:
> > >  rtw88: usb: route bmc frames via the high queue only for DTIM delivery")
> > >  and the two commits that followed it. Use the same rule for SDIO. A bmc
> > >  frame goes to the high queue only when mac80211 asks for DTIM delivery
> > >  because a station is dozing, the frame is ARP, EAPOL or DHCP, and the
> > >  budget allows it. All other bmc frames go out on their access category
> > >  queue.
> > >
> > I'd remove second paragraph since it just describes the patch 1/2 does.
> >
> 
> Would you be willing to drop it your when applying?

Sure. I'll do it.

RE: [PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Ping-Ke Shih]

Luka Gejak <luka.gejak@linux.dev> wrote:
> USB decides in usb.c which broadcast and multicast (bmc) frames may use
> the high queue. SDIO needs the same decision, so move the helpers to
> tx.c behind a single exported rtw_tx_bmc_use_hiq() and keep the budget
> state in struct rtw_dev.
> 
> No functional change.

By my review, I think it doesn't change logic at all, but I hope if
someone can help to test USB devices to confirm it still works well.

> 
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

Re: [PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Luka Gejak]

October 22, 2026 at 4:20 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:


> 
> Luka Gejak <luka.gejak@linux.dev> wrote:
> 
> > 
> > USB decides in usb.c which broadcast and multicast (bmc) frames may use
> >  the high queue. SDIO needs the same decision, so move the helpers to
> >  tx.c behind a single exported rtw_tx_bmc_use_hiq() and keep the budget
> >  state in struct rtw_dev.
> >  
> >  No functional change.
> > 
> By my review, I think it doesn't change logic at all, but I hope if
> someone can help to test USB devices to confirm it still works well.
> 

I ran the same test with rtl8723du and there is no regression.

Best regards,
Luka Gejak

Re: [PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Luka Gejak]

Hi Ping-Ke,

October 22, 2026 at 7:11 AM, "Luka Gejak" <luka.gejak@linux.dev> wrote:


> 
> October 22, 2026 at 4:20 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:
> 
> > 
> > Luka Gejak <luka.gejak@linux.dev> wrote:
> >  
> >  
> >  USB decides in usb.c which broadcast and multicast (bmc) frames may use
> >  the high queue. SDIO needs the same decision, so move the helpers to
> >  tx.c behind a single exported rtw_tx_bmc_use_hiq() and keep the budget
> >  state in struct rtw_dev.
> >  
> >  No functional change.
> >  
> >  By my review, I think it doesn't change logic at all, but I hope if
> >  someone can help to test USB devices to confirm it still works well.
> > 
> I ran the same test with rtl8723du and there is no regression.
> 
> Best regards,
> Luka Gejak
>

I was thinking, as staging got removed, for 10-ish weeks(until 7.5)
users of RTL8723BS won't have AP mode. So I was wondering if these two
patches could pass as fixes into rc2 release(or whatever is the first
rc into which rtw tree is merged), as this would be DHCP stall fix. To
elaborate: when this driver was merged it, was exposingAP mode to
userspace, due to RTW88 doing it globally. Therefore AP mode existed,
but wasn't working properly. So maybe it's a bit of a stretch, but I
think it's a valid proposal to send it as a fix into next rc release.

Best regards,
Luka Gejak

RE: [PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Ping-Ke Shih]

Luka Gejak <luka.gejak@linux.dev> wrote:
> I was thinking, as staging got removed, for 10-ish weeks(until 7.5)
> users of RTL8723BS won't have AP mode. So I was wondering if these two
> patches could pass as fixes into rc2 release(or whatever is the first
> rc into which rtw tree is merged), as this would be DHCP stall fix. To
> elaborate: when this driver was merged it, was exposingAP mode to
> userspace, due to RTW88 doing it globally. Therefore AP mode existed,
> but wasn't working properly. So maybe it's a bit of a stretch, but I
> think it's a valid proposal to send it as a fix into next rc release.

Did you think people use staging driver with AP mode? 

Personally, I want this goes to rtw-next, but if you have strong opinion
that people need this. I can pick them and let it goes to -rc. 

Ping-Ke

Re: [PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Luka Gejak]

October 25, 2026 at 3:49 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:


> 
> Luka Gejak <luka.gejak@linux.dev> wrote:
> 
> > 
> > I was thinking, as staging got removed, for 10-ish weeks(until 7.5)
> >  users of RTL8723BS won't have AP mode. So I was wondering if these two
> >  patches could pass as fixes into rc2 release(or whatever is the first
> >  rc into which rtw tree is merged), as this would be DHCP stall fix. To
> >  elaborate: when this driver was merged it, was exposingAP mode to
> >  userspace, due to RTW88 doing it globally. Therefore AP mode existed,
> >  but wasn't working properly. So maybe it's a bit of a stretch, but I
> >  think it's a valid proposal to send it as a fix into next rc release.
> > 
> Did you think people use staging driver with AP mode? 

It appears so. I saw on forums and articles about the new driver that
some people were complaining because only station mode is working
because they exclusively or mostly use it as an AP point.

> 
> Personally, I want this goes to rtw-next, but if you have strong opinion
> that people need this. I can pick them and let it goes to -rc.

I think it would be better to pick these into rc, especially since
the feature exists right now but is broken.

Best regards,
Luka Gejak

RE: [PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Ping-Ke Shih]

Luka Gejak <luka.gejak@linux.dev> wrote:
> October 25, 2026 at 3:49 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:
> >
> > Luka Gejak <luka.gejak@linux.dev> wrote:
> >
> > >
> > > I was thinking, as staging got removed, for 10-ish weeks(until 7.5)
> > >  users of RTL8723BS won't have AP mode. So I was wondering if these two
> > >  patches could pass as fixes into rc2 release(or whatever is the first
> > >  rc into which rtw tree is merged), as this would be DHCP stall fix. To
> > >  elaborate: when this driver was merged it, was exposingAP mode to
> > >  userspace, due to RTW88 doing it globally. Therefore AP mode existed,
> > >  but wasn't working properly. So maybe it's a bit of a stretch, but I
> > >  think it's a valid proposal to send it as a fix into next rc release.
> > >
> > Did you think people use staging driver with AP mode?
> 
> It appears so. I saw on forums and articles about the new driver that
> some people were complaining because only station mode is working
> because they exclusively or mostly use it as an AP point.

This lets me think if I merge RTL8723BS to rtw88 and delete rtl8723bs 
from staging too early. The staging rtl8723bs is a vendor driver which
mostly implements "full" functions, but rtw88 should be not. To smoothly
migrate from staging to rtw88, we should implement equivalent functions
before merging, at least functions people are using. 

But I really don't want to go back to staging driver. Let's pick the
fixes of AP mode. I hope no more functions needed to be picked. 

> 
> >
> > Personally, I want this goes to rtw-next, but if you have strong opinion
> > that people need this. I can pick them and let it goes to -rc.
> 
> I think it would be better to pick these into rc, especially since
> the feature exists right now but is broken.

Comparing to staging rtl8723bs, it might be seen as broken, but for rtw88
I consider this as a new feature. 

Ping-Ke

Re: [PATCH rtw-next v2 1/2] wifi: rtw88: move the bmc high queue decision to tx.c

[Luka Gejak]

October 27, 2026 at 2:19 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:


> 
> Luka Gejak <luka.gejak@linux.dev> wrote:
> 
> > 
> > October 25, 2026 at 3:49 AM, "Ping-Ke Shih" <pkshih@realtek.com> wrote:
> > 
> >  Luka Gejak <luka.gejak@linux.dev> wrote:
> > 
> >  >
> >  > I was thinking, as staging got removed, for 10-ish weeks(until 7.5)
> >  > users of RTL8723BS won't have AP mode. So I was wondering if these two
> >  > patches could pass as fixes into rc2 release(or whatever is the first
> >  > rc into which rtw tree is merged), as this would be DHCP stall fix. To
> >  > elaborate: when this driver was merged it, was exposingAP mode to
> >  > userspace, due to RTW88 doing it globally. Therefore AP mode existed,
> >  > but wasn't working properly. So maybe it's a bit of a stretch, but I
> >  > think it's a valid proposal to send it as a fix into next rc release.
> >  >
> >  Did you think people use staging driver with AP mode?
> >  
> >  It appears so. I saw on forums and articles about the new driver that
> >  some people were complaining because only station mode is working
> >  because they exclusively or mostly use it as an AP point.
> > 
> This lets me think if I merge RTL8723BS to rtw88 and delete rtl8723bs 
> from staging too early. The staging rtl8723bs is a vendor driver which
> mostly implements "full" functions, but rtw88 should be not. To smoothly
> migrate from staging to rtw88, we should implement equivalent functions
> before merging, at least functions people are using. 
> 
> But I really don't want to go back to staging driver. Let's pick the
> fixes of AP mode. I hope no more functions needed to be picked. 

That is the only thing needed to pick. Other things are already implemented.

Best regards,
Luka Gejak