[PATCH rtw-next 0/5] wifi: rtlwifi: rtl8192du fixes and additional support

[PATCH rtw-next 0/5] wifi: rtlwifi: rtl8192du fixes and additional support

[Ho Jie Feng]

Fixes
- BA sessions started for QoS null frames
- signal of A-MPDU frames without PHY status
- rate mask limited by rssi_level, which is always 0

Implements
- USB RX aggregation

Tested on RTL8192DU 2.4 GHz with iperf3.
Testing on 5 GHz did not show any changes.

   before after
TX 7.0    12.6
RX 28.3   39.1

Ho Jie Feng (5):
  wifi: rtlwifi: rc: start no BA session for QoS null frames
  wifi: rtlwifi: rtl8192d: report no signal for frames without PHY
    status
  wifi: rtlwifi: usb: unify the RX code path
  wifi: rtlwifi: rtl8192du: enable USB RX aggregation
  wifi: rtlwifi: rtl8192d: let the firmware use all rates

 drivers/net/wireless/realtek/rtlwifi/rc.c     |  2 +-
 .../realtek/rtlwifi/rtl8192d/hw_common.c      | 12 ++---
 .../wireless/realtek/rtlwifi/rtl8192d/reg.h   |  4 ++
 .../realtek/rtlwifi/rtl8192d/trx_common.c     |  3 ++
 .../wireless/realtek/rtlwifi/rtl8192du/hw.c   | 18 ++++++-
 .../wireless/realtek/rtlwifi/rtl8192du/sw.c   |  2 +-
 .../wireless/realtek/rtlwifi/rtl8192du/trx.c  | 45 ++++++++++++++++
 .../wireless/realtek/rtlwifi/rtl8192du/trx.h  |  5 ++
 drivers/net/wireless/realtek/rtlwifi/usb.c    | 52 ++-----------------
 9 files changed, 85 insertions(+), 58 deletions(-)


base-commit: dc16902cad9c6b08df9395a510c7be44fbab545d
-- 
2.53.0

[PATCH rtw-next 1/5] wifi: rtlwifi: rc: start no BA session for QoS null frames

[Ho Jie Feng]

Only start BA sessions for frames that carry data.

Test results (2.4 GHz):
   before after
TX 7.0    6.1
RX 28.3   29.1

Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
---
 drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c b/drivers/net/wireless/realtek/rtlwifi/rc.c
index dcfaa98198b612..f475f1b8a98272 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -216,7 +216,7 @@ static void rtl_tx_status(void *ppriv,
 	__le16 fc = rtl_get_fc(skb);
 	struct rtl_sta_info *sta_entry;
 
-	if (!priv_sta || !ieee80211_is_data(fc))
+	if (!priv_sta || !ieee80211_is_data_present(fc))
 		return;
 
 	if (rtl_is_special_data(mac->hw, skb, true, true))
-- 
2.53.0

RE: [PATCH rtw-next 1/5] wifi: rtlwifi: rc: start no BA session for QoS null frames

[Ping-Ke Shih]

Ho Jie Feng <hjf3108@gmail.com> wrote:
> Only start BA sessions for frames that carry data.

I can't understand why building a BA session for null frames cause lower
throughput? Please explain why.

> 
> Test results (2.4 GHz):
>    before after
> TX 7.0    6.1
> RX 28.3   29.1
> 
> Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>

Re: [PATCH rtw-next 1/5] wifi: rtlwifi: rc: start no BA session for QoS null frames

[Jie Feng]

On Sun, 8 Nov 2026 at 11:08, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Ho Jie Feng <hjf3108@gmail.com> wrote:
> > Only start BA sessions for frames that carry data.
>
> I can't understand why building a BA session for null frames cause lower
> throughput? Please explain why.
I included the throughput numbers as a regression test, to show that it does not
cause any speed regressions. It should not affect throughput.

> >
> > Test results (2.4 GHz):
> >    before after
> > TX 7.0    6.1
> > RX 28.3   29.1
> >
> > Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
>
>

RE: [PATCH rtw-next 1/5] wifi: rtlwifi: rc: start no BA session for QoS null frames

[Ping-Ke Shih]

Jie Feng <hjf3108@gmail.com> wrote:
> On Sun, 8 Nov 2026 at 11:08, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Ho Jie Feng <hjf3108@gmail.com> wrote:
> > > Only start BA sessions for frames that carry data.
> >
> > I can't understand why building a BA session for null frames cause lower
> > throughput? Please explain why.
> I included the throughput numbers as a regression test, to show that it does not
> cause any speed regressions. It should not affect throughput.

Please drop the numbers from this patch. 

[PATCH rtw-next 2/5] wifi: rtlwifi: rtl8192d: report no signal for frames without PHY status

[Ho Jie Feng]

Only the first frame of an A-MPDU comes with the PHY status.
This makes mac80211 report the correct value when queried from iw.

Test results (2.4 GHz):
   before after
TX 6.1    5.2
RX 29.1   27.1

Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
index 9f9a34492030c6..a8910cdbfa0979 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
@@ -425,6 +425,9 @@ bool rtl92d_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
 						     stats->rx_bufshift);
 		_rtl92d_translate_rx_signal_stuff(hw, skb, stats, pdesc,
 						  p_drvinfo);
+	} else {
+		/* Only the first frame of an A-MPDU has the PHY status. */
+		rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
 	}
 	/*rx_status->qual = stats->signal; */
 	rx_status->signal = stats->recvsignalpower + 10;
-- 
2.53.0

RE: [PATCH rtw-next 2/5] wifi: rtlwifi: rtl8192d: report no signal for frames without PHY status

[Ping-Ke Shih]

Ho Jie Feng <hjf3108@gmail.com> wrote:
> Only the first frame of an A-MPDU comes with the PHY status.
> This makes mac80211 report the correct value when queried from iw.
> 
> Test results (2.4 GHz):
>    before after
> TX 6.1    5.2
> RX 29.1   27.1

How does improper RX_FLAG_NO_SIGNAL_VAL affect throughput? 

> 
> Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
> ---
>  drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> index 9f9a34492030c6..a8910cdbfa0979 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> @@ -425,6 +425,9 @@ bool rtl92d_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
>                                                      stats->rx_bufshift);
>                 _rtl92d_translate_rx_signal_stuff(hw, skb, stats, pdesc,
>                                                   p_drvinfo);
> +       } else {
> +               /* Only the first frame of an A-MPDU has the PHY status. */

It is clear that this branch is !phystatus, so no need comment. 

> +               rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
>         }
>         /*rx_status->qual = stats->signal; */
>         rx_status->signal = stats->recvsignalpower + 10;
> --
> 2.53.0

Re: [PATCH rtw-next 2/5] wifi: rtlwifi: rtl8192d: report no signal for frames without PHY status

[Jie Feng]

On Sun, 8 Nov 2026 at 11:13, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Ho Jie Feng <hjf3108@gmail.com> wrote:
> > Only the first frame of an A-MPDU comes with the PHY status.
> > This makes mac80211 report the correct value when queried from iw.
> >
> > Test results (2.4 GHz):
> >    before after
> > TX 6.1    5.2
> > RX 29.1   27.1
>
> How does improper RX_FLAG_NO_SIGNAL_VAL affect throughput?
I included the throughput numbers as a regression test, to show that it does not
cause any speed regressions. It should not affect throughput.
> >
> > Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
> > ---
> >  drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > index 9f9a34492030c6..a8910cdbfa0979 100644
> > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > @@ -425,6 +425,9 @@ bool rtl92d_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
> >                                                      stats->rx_bufshift);
> >                 _rtl92d_translate_rx_signal_stuff(hw, skb, stats, pdesc,
> >                                                   p_drvinfo);
> > +       } else {
> > +               /* Only the first frame of an A-MPDU has the PHY status. */
>
> It is clear that this branch is !phystatus, so no need comment.
Will be removed in v2 of the patch series.

> > +               rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
> >         }
> >         /*rx_status->qual = stats->signal; */
> >         rx_status->signal = stats->recvsignalpower + 10;
> > --
> > 2.53.0
>

RE: [PATCH rtw-next 2/5] wifi: rtlwifi: rtl8192d: report no signal for frames without PHY status

[Ping-Ke Shih]

Jie Feng <hjf3108@gmail.com> wrote:
> On Sun, 8 Nov 2026 at 11:13, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Ho Jie Feng <hjf3108@gmail.com> wrote:
> > > Only the first frame of an A-MPDU comes with the PHY status.
> > > This makes mac80211 report the correct value when queried from iw.
> > >
> > > Test results (2.4 GHz):
> > >    before after
> > > TX 6.1    5.2
> > > RX 29.1   27.1
> >
> > How does improper RX_FLAG_NO_SIGNAL_VAL affect throughput?
> I included the throughput numbers as a regression test, to show that it does not
> cause any speed regressions. It should not affect throughput.

Remove the numbers. Or at least mention it doesn't affect throughput.

> > >
> > > Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
> > > ---
> > >  drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > > b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > > index 9f9a34492030c6..a8910cdbfa0979 100644
> > > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/trx_common.c
> > > @@ -425,6 +425,9 @@ bool rtl92d_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
> > >                                                      stats->rx_bufshift);
> > >                 _rtl92d_translate_rx_signal_stuff(hw, skb, stats, pdesc,
> > >                                                   p_drvinfo);
> > > +       } else {
> > > +               /* Only the first frame of an A-MPDU has the PHY status. */
> >
> > It is clear that this branch is !phystatus, so no need comment.
> Will be removed in v2 of the patch series.

Wait a while, since patchwork and lore for wireless are broken. It is hard
to me to trace patches... 

> 
> > > +               rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
> > >         }
> > >         /*rx_status->qual = stats->signal; */
> > >         rx_status->signal = stats->recvsignalpower + 10;
> > > --
> > > 2.53.0
> >

[PATCH rtw-next 3/5] wifi: rtlwifi: usb: unify the RX code path

[Ho Jie Feng]

_rtl_usb_rx_process_agg is a copy of _rtl_usb_rx_process_noagg
except without the tail end. The noagg function can be used for
aggregated frames, so drop it and rename _rtl_usb_rx_process_noagg
to _rtl_usb_rx_process to unify the code path.

Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
---
 drivers/net/wireless/realtek/rtlwifi/usb.c | 52 ++--------------------
 1 file changed, 3 insertions(+), 49 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index d013e5986948b5..d7b3192262c001 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -366,50 +366,7 @@ static int _rtl_prep_rx_urb(struct ieee80211_hw *hw, struct rtl_usb *rtlusb,
 	return 0;
 }
 
-static void _rtl_usb_rx_process_agg(struct ieee80211_hw *hw,
-				    struct sk_buff *skb)
-{
-	struct rtl_priv *rtlpriv = rtl_priv(hw);
-	u8 *rxdesc = skb->data;
-	struct ieee80211_hdr *hdr;
-	bool unicast = false;
-	__le16 fc;
-	struct ieee80211_rx_status rx_status = {0};
-	struct rtl_stats stats = {
-		.signal = 0,
-		.rate = 0,
-	};
-
-	skb_pull(skb, RTL_RX_DESC_SIZE);
-	rtlpriv->cfg->ops->query_rx_desc(hw, &stats, &rx_status, rxdesc, skb);
-	skb_pull(skb, (stats.rx_drvinfo_size + stats.rx_bufshift));
-	hdr = rtl_get_hdr(skb);
-	fc = hdr->frame_control;
-	if (!stats.crc) {
-		memcpy(IEEE80211_SKB_RXCB(skb), &rx_status, sizeof(rx_status));
-
-		if (is_broadcast_ether_addr(hdr->addr1)) {
-			/*TODO*/;
-		} else if (is_multicast_ether_addr(hdr->addr1)) {
-			/*TODO*/
-		} else {
-			unicast = true;
-			rtlpriv->stats.rxbytesunicast +=  skb->len;
-		}
-
-		if (ieee80211_is_data(fc)) {
-			rtlpriv->cfg->ops->led_control(hw, LED_CTL_RX);
-
-			if (unicast)
-				rtlpriv->link_info.num_rx_inperiod++;
-		}
-		/* static bcn for roaming */
-		rtl_beacon_statistic(hw, skb);
-	}
-}
-
-static void _rtl_usb_rx_process_noagg(struct ieee80211_hw *hw,
-				      struct sk_buff *skb)
+static void _rtl_usb_rx_process(struct ieee80211_hw *hw, struct sk_buff *skb)
 {
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
 	u8 *rxdesc = skb->data;
@@ -470,8 +427,7 @@ static void _rtl_rx_pre_process(struct ieee80211_hw *hw, struct sk_buff *skb)
 	WARN_ON(skb_queue_empty(&rx_queue));
 	while (!skb_queue_empty(&rx_queue)) {
 		_skb = skb_dequeue(&rx_queue);
-		_rtl_usb_rx_process_agg(hw, _skb);
-		ieee80211_rx(hw, _skb);
+		_rtl_usb_rx_process(hw, _skb);
 	}
 }
 
@@ -490,11 +446,9 @@ static void _rtl_rx_work(struct tasklet_struct *t)
 		}
 
 		if (likely(!rtlusb->usb_rx_segregate_hdl)) {
-			_rtl_usb_rx_process_noagg(hw, skb);
+			_rtl_usb_rx_process(hw, skb);
 		} else {
-			/* TO DO */
 			_rtl_rx_pre_process(hw, skb);
-			pr_err("rx agg not supported\n");
 		}
 	}
 }
-- 
2.53.0

RE: [PATCH rtw-next 3/5] wifi: rtlwifi: usb: unify the RX code path

[Ping-Ke Shih]

Ho Jie Feng <hjf3108@gmail.com> wrote:
> _rtl_usb_rx_process_agg is a copy of _rtl_usb_rx_process_noagg
> except without the tail end. The noagg function can be used for
> aggregated frames, so drop it and rename _rtl_usb_rx_process_noagg
> to _rtl_usb_rx_process to unify the code path.
> 
> Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>

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

[PATCH rtw-next 4/5] wifi: rtlwifi: rtl8192du: enable USB RX aggregation

[Ho Jie Feng]

Allow RX aggregation of up to 48 pages of 128 bytes or 24 with two MACs.

Test results (2.4 GHz):
   before after
TX 5.2    6.4
RX 27.1   32.0

Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
---
 .../wireless/realtek/rtlwifi/rtl8192d/reg.h   |  4 ++
 .../wireless/realtek/rtlwifi/rtl8192du/hw.c   | 18 +++++++-
 .../wireless/realtek/rtlwifi/rtl8192du/sw.c   |  2 +-
 .../wireless/realtek/rtlwifi/rtl8192du/trx.c  | 45 +++++++++++++++++++
 .../wireless/realtek/rtlwifi/rtl8192du/trx.h  |  5 +++
 5 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/reg.h b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/reg.h
index 639aa0d92e05ef..7cc46f411af88b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/reg.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/reg.h
@@ -329,6 +329,7 @@
 
 #define REG_USB_Queue_Select_MAC0	0xFE44
 #define REG_USB_Queue_Select_MAC1	0xFE47
+#define REG_USB_DMA_AGG_TO		0xFE5B
 
 /* ----------------------------------------------------- */
 /*	Redifine 8192C register definition for compatibility */
@@ -940,6 +941,9 @@
 #define ENSWBCN					BIT(8)
 #define ENSEC					BIT(9)
 
+/* REG_TRXDMA_CTRL */
+#define RXDMA_AGG_EN				BIT(2)
+
 #define HQSEL_VOQ				BIT(0)
 #define HQSEL_VIQ				BIT(1)
 #define HQSEL_BEQ				BIT(2)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c
index ff458fb8514dae..3edd5bc432ff7c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c
@@ -489,6 +489,22 @@ static void _rtl92du_init_retry_function(struct ieee80211_hw *hw)
 	rtl_write_byte(rtlpriv, REG_ACKTO, 0x40);
 }
 
+static void _rtl92du_init_usb_aggregation(struct ieee80211_hw *hw)
+{
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	u8 page_count = 48;
+
+	if (rtlpriv->rtlhal.macphymode != SINGLEMAC_SINGLEPHY)
+		page_count = 24;
+
+	rtl_write_byte(rtlpriv, REG_TRXDMA_CTRL,
+		       rtl_read_byte(rtlpriv, REG_TRXDMA_CTRL) | RXDMA_AGG_EN);
+	/* unit: 128 bytes */
+	rtl_write_byte(rtlpriv, REG_RXDMA_AGG_PG_TH, page_count);
+	/* A larger value is a shorter timeout. */
+	rtl_write_byte(rtlpriv, REG_USB_DMA_AGG_TO, 6);
+}
+
 static void _rtl92du_init_operation_mode(struct ieee80211_hw *hw)
 {
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -712,7 +728,7 @@ int rtl92du_hw_init(struct ieee80211_hw *hw)
 	rtl_write_dword(rtlpriv, REG_RARFRC + 4, 0x08070605);
 
 	_rtl92du_init_retry_function(hw);
-	/* _InitUsbAggregationSetting(padapter); no aggregation for now */
+	_rtl92du_init_usb_aggregation(hw);
 	_rtl92du_init_operation_mode(hw);
 	_rtl92du_init_beacon_parameters(hw);
 	_rtl92du_init_ampdu_aggregation(hw);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/sw.c
index 88e8cc590c544b..6b90002b69f41a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/sw.c
@@ -238,7 +238,7 @@ static const struct rtl_hal_usbint_cfg rtl92du_interface_cfg = {
 	.rx_urb_num = 8,
 	.rx_max_size = 15360,
 	.usb_rx_hdl = NULL,
-	.usb_rx_segregate_hdl = NULL,
+	.usb_rx_segregate_hdl = rtl92du_rx_segregate_hdl,
 	/* tx */
 	.usb_tx_cleanup = rtl92du_tx_cleanup,
 	.usb_tx_post_hdl = rtl92du_tx_post_hdl,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.c
index c608c51f1b785c..13364cdc7fa367 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.c
@@ -19,6 +19,51 @@ int rtl92du_tx_post_hdl(struct ieee80211_hw *hw, struct urb *urb,
 	return 0;
 }
 
+void rtl92du_rx_segregate_hdl(struct ieee80211_hw *hw, struct sk_buff *skb,
+			      struct sk_buff_head *queue)
+{
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	unsigned int offset = 0, pkt_size;
+	struct sk_buff *new_skb;
+	__le32 *rxdesc;
+
+	while (skb->len - offset >= RTL_RX_DESC_SIZE) {
+		rxdesc = (__le32 *)(skb->data + offset);
+		pkt_size = RTL_RX_DESC_SIZE +
+			   get_rx_desc_drv_info_size(rxdesc) *
+			   RX_DRV_INFO_SIZE_UNIT +
+			   get_rx_desc_shift(rxdesc) +
+			   get_rx_desc_pkt_len(rxdesc);
+
+		if (get_rx_desc_pkt_len(rxdesc) == 0 ||
+		    pkt_size > skb->len - offset) {
+			rtl_dbg(rtlpriv, COMP_RECV, DBG_WARNING,
+				"bad frame at %u of %u, size %u\n",
+				offset, skb->len, pkt_size);
+			break;
+		}
+
+		/* The last frame keeps the original skb. */
+		if (ALIGN(pkt_size, RTL92DU_RX_AGG_ALIGN) >= skb->len - offset) {
+			skb_pull(skb, offset);
+			skb_trim(skb, pkt_size);
+			__skb_queue_tail(queue, skb);
+			return;
+		}
+
+		new_skb = dev_alloc_skb(pkt_size + RTL92DU_RX_HEADROOM);
+		if (!new_skb)
+			break;
+		skb_reserve(new_skb, RTL92DU_RX_HEADROOM);
+		skb_put_data(new_skb, rxdesc, pkt_size);
+		__skb_queue_tail(queue, new_skb);
+
+		offset += ALIGN(pkt_size, RTL92DU_RX_AGG_ALIGN);
+	}
+
+	dev_kfree_skb_any(skb);
+}
+
 struct sk_buff *rtl92du_tx_aggregate_hdl(struct ieee80211_hw *hw,
 					 struct sk_buff_head *list)
 {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.h b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.h
index 8c3d24622fa7ce..807245a91bbee3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.h
@@ -18,6 +18,9 @@
 
 #define WMM_NORMAL_TX_TOTAL_PAGE_NUMBER			0xF5
 
+#define RTL92DU_RX_HEADROOM				32
+#define RTL92DU_RX_AGG_ALIGN				128
+
 #define WMM_NORMAL_PAGE_NUM_PUBQ_92D			0x65
 #define WMM_NORMAL_PAGE_NUM_HPQ_92D			0x30
 #define WMM_NORMAL_PAGE_NUM_LPQ_92D			0x30
@@ -56,5 +59,7 @@ struct sk_buff *rtl92du_tx_aggregate_hdl(struct ieee80211_hw *hw,
 void rtl92du_tx_cleanup(struct ieee80211_hw *hw, struct sk_buff  *skb);
 int rtl92du_tx_post_hdl(struct ieee80211_hw *hw, struct urb *urb,
 			struct sk_buff *skb);
+void rtl92du_rx_segregate_hdl(struct ieee80211_hw *hw, struct sk_buff *skb,
+			      struct sk_buff_head *queue);
 
 #endif
-- 
2.53.0

RE: [PATCH rtw-next 4/5] wifi: rtlwifi: rtl8192du: enable USB RX aggregation

[Ping-Ke Shih]

Ho Jie Feng <hjf3108@gmail.com> wrote:
> Allow RX aggregation of up to 48 pages of 128 bytes or 24 with two MACs.

You can describe a little bit how you build separate skb, especially
the last one. 

> 
> Test results (2.4 GHz):
>    before after
> TX 5.2    6.4
> RX 27.1   32.0
> 
> Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>

Acked-by is given, but some minor comments.

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

> +void rtl92du_rx_segregate_hdl(struct ieee80211_hw *hw, struct sk_buff *skb,
> +                             struct sk_buff_head *queue)
> +{
> +       struct rtl_priv *rtlpriv = rtl_priv(hw);
> +       unsigned int offset = 0, pkt_size;
> +       struct sk_buff *new_skb;
> +       __le32 *rxdesc;
> +
> +       while (skb->len - offset >= RTL_RX_DESC_SIZE) {
> +               rxdesc = (__le32 *)(skb->data + offset);
> +               pkt_size = RTL_RX_DESC_SIZE +
> +                          get_rx_desc_drv_info_size(rxdesc) *
> +                          RX_DRV_INFO_SIZE_UNIT +
> +                          get_rx_desc_shift(rxdesc) +
> +                          get_rx_desc_pkt_len(rxdesc);
> +
> +               if (get_rx_desc_pkt_len(rxdesc) == 0 ||
> +                   pkt_size > skb->len - offset) {
> +                       rtl_dbg(rtlpriv, COMP_RECV, DBG_WARNING,
> +                               "bad frame at %u of %u, size %u\n",
> +                               offset, skb->len, pkt_size);
> +                       break;
> +               }
> +
> +               /* The last frame keeps the original skb. */
> +               if (ALIGN(pkt_size, RTL92DU_RX_AGG_ALIGN) >= skb->len - offset) {
> +                       skb_pull(skb, offset);
> +                       skb_trim(skb, pkt_size);
> +                       __skb_queue_tail(queue, skb);
> +                       return;
> +               }
> +
> +               new_skb = dev_alloc_skb(pkt_size + RTL92DU_RX_HEADROOM);

What is the purpose of RTL92DU_RX_HEADROOM ?

> +               if (!new_skb)
> +                       break;
> +               skb_reserve(new_skb, RTL92DU_RX_HEADROOM);
> +               skb_put_data(new_skb, rxdesc, pkt_size);
> +               __skb_queue_tail(queue, new_skb);
> +
> +               offset += ALIGN(pkt_size, RTL92DU_RX_AGG_ALIGN);
> +       }
> +
> +       dev_kfree_skb_any(skb);
> +}
> +

Re: [PATCH rtw-next 4/5] wifi: rtlwifi: rtl8192du: enable USB RX aggregation

[Jie Feng]

On Mon, 9 Nov 2026 at 08:44, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Ho Jie Feng <hjf3108@gmail.com> wrote:
> > Allow RX aggregation of up to 48 pages of 128 bytes or 24 with two MACs.
>
> You can describe a little bit how you build separate skb, especially
> the last one.
>
> >
> > Test results (2.4 GHz):
> >    before after
> > TX 5.2    6.4
> > RX 27.1   32.0
> >
> > Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
>
> Acked-by is given, but some minor comments.
>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
>
> > +void rtl92du_rx_segregate_hdl(struct ieee80211_hw *hw, struct sk_buff *skb,
> > +                             struct sk_buff_head *queue)
> > +{
> > +       struct rtl_priv *rtlpriv = rtl_priv(hw);
> > +       unsigned int offset = 0, pkt_size;
> > +       struct sk_buff *new_skb;
> > +       __le32 *rxdesc;
> > +
> > +       while (skb->len - offset >= RTL_RX_DESC_SIZE) {
> > +               rxdesc = (__le32 *)(skb->data + offset);
> > +               pkt_size = RTL_RX_DESC_SIZE +
> > +                          get_rx_desc_drv_info_size(rxdesc) *
> > +                          RX_DRV_INFO_SIZE_UNIT +
> > +                          get_rx_desc_shift(rxdesc) +
> > +                          get_rx_desc_pkt_len(rxdesc);
> > +
> > +               if (get_rx_desc_pkt_len(rxdesc) == 0 ||
> > +                   pkt_size > skb->len - offset) {
> > +                       rtl_dbg(rtlpriv, COMP_RECV, DBG_WARNING,
> > +                               "bad frame at %u of %u, size %u\n",
> > +                               offset, skb->len, pkt_size);
> > +                       break;
> > +               }
> > +
> > +               /* The last frame keeps the original skb. */
> > +               if (ALIGN(pkt_size, RTL92DU_RX_AGG_ALIGN) >= skb->len - offset) {
> > +                       skb_pull(skb, offset);
> > +                       skb_trim(skb, pkt_size);
> > +                       __skb_queue_tail(queue, skb);
> > +                       return;
> > +               }
> > +
> > +               new_skb = dev_alloc_skb(pkt_size + RTL92DU_RX_HEADROOM);
>
> What is the purpose of RTL92DU_RX_HEADROOM ?
This is for the radiotap header, like in usb.c.

I could drop it, or add comments or a commit description to describe it?

https://github.com/pkshih/rtw/blob/rtw-next/drivers/net/wireless/realtek/rtlwifi/usb.c#L582
> > +               if (!new_skb)
> > +                       break;
> > +               skb_reserve(new_skb, RTL92DU_RX_HEADROOM);
> > +               skb_put_data(new_skb, rxdesc, pkt_size);
> > +               __skb_queue_tail(queue, new_skb);
> > +
> > +               offset += ALIGN(pkt_size, RTL92DU_RX_AGG_ALIGN);
> > +       }
> > +
> > +       dev_kfree_skb_any(skb);
> > +}
> > +
>
>

RE: [PATCH rtw-next 4/5] wifi: rtlwifi: rtl8192du: enable USB RX aggregation

[Ping-Ke Shih]

Jie Feng <hjf3108@gmail.com> wrote:
> On Mon, 9 Nov 2026 at 08:44, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Ho Jie Feng <hjf3108@gmail.com> wrote:
> > > Allow RX aggregation of up to 48 pages of 128 bytes or 24 with two MACs.
> >
> > You can describe a little bit how you build separate skb, especially
> > the last one.
> >
> > >
> > > Test results (2.4 GHz):
> > >    before after
> > > TX 5.2    6.4
> > > RX 27.1   32.0
> > >
> > > Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
> >
> > Acked-by is given, but some minor comments.
> >
> > Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> >
> > > +void rtl92du_rx_segregate_hdl(struct ieee80211_hw *hw, struct sk_buff *skb,
> > > +                             struct sk_buff_head *queue)
> > > +{
> > > +       struct rtl_priv *rtlpriv = rtl_priv(hw);
> > > +       unsigned int offset = 0, pkt_size;
> > > +       struct sk_buff *new_skb;
> > > +       __le32 *rxdesc;
> > > +
> > > +       while (skb->len - offset >= RTL_RX_DESC_SIZE) {
> > > +               rxdesc = (__le32 *)(skb->data + offset);
> > > +               pkt_size = RTL_RX_DESC_SIZE +
> > > +                          get_rx_desc_drv_info_size(rxdesc) *
> > > +                          RX_DRV_INFO_SIZE_UNIT +
> > > +                          get_rx_desc_shift(rxdesc) +
> > > +                          get_rx_desc_pkt_len(rxdesc);
> > > +
> > > +               if (get_rx_desc_pkt_len(rxdesc) == 0 ||
> > > +                   pkt_size > skb->len - offset) {
> > > +                       rtl_dbg(rtlpriv, COMP_RECV, DBG_WARNING,
> > > +                               "bad frame at %u of %u, size %u\n",
> > > +                               offset, skb->len, pkt_size);
> > > +                       break;
> > > +               }
> > > +
> > > +               /* The last frame keeps the original skb. */
> > > +               if (ALIGN(pkt_size, RTL92DU_RX_AGG_ALIGN) >= skb->len - offset) {
> > > +                       skb_pull(skb, offset);
> > > +                       skb_trim(skb, pkt_size);
> > > +                       __skb_queue_tail(queue, skb);
> > > +                       return;
> > > +               }
> > > +
> > > +               new_skb = dev_alloc_skb(pkt_size + RTL92DU_RX_HEADROOM);
> >
> > What is the purpose of RTL92DU_RX_HEADROOM ?
> This is for the radiotap header, like in usb.c.
> 
> I could drop it, or add comments or a commit description to describe it?

Why not just naming RADIOTAP like usb.c ?

> 
> https://github.com/pkshih/rtw/blob/rtw-next/drivers/net/wireless/realtek/rtlwifi/usb.c#L582

I don't remember I have tried monitor mode with rtlwifi. Can you give it a try? 

[PATCH rtw-next 5/5] wifi: rtlwifi: rtl8192d: let the firmware use all rates

[Ho Jie Feng]

The rate mask is chosen based on rssi_level, however rssi_level
is always 0, since:
- for rtl8192de, call to rtl92d_dm_refresh_rate_adaptive_mask is
  commented out and function is not implemented
- for rtl8192du, it is also not called.

This makes the branch always choose less than optimal allowed MCS rates.
Enable all the rates.

Test results (2.4 GHz):
   before after
TX 6.4    12.6
RX 32.0   39.1

Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
---
 .../wireless/realtek/rtlwifi/rtl8192d/hw_common.c    | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
index cfefbe86380fbc..0c921c049b5178 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
@@ -903,7 +903,7 @@ static void rtl92d_update_hal_rate_mask(struct ieee80211_hw *hw,
 		else if (rssi_level == 2)
 			ratr_bitmap &= 0x00000ff0;
 		else
-			ratr_bitmap &= 0x00000ff5;
+			ratr_bitmap &= 0x00000fff;
 		break;
 	case WIRELESS_MODE_A:
 		ratr_index = RATR_INX_WIRELESS_G;
@@ -922,7 +922,7 @@ static void rtl92d_update_hal_rate_mask(struct ieee80211_hw *hw,
 			else if (rssi_level == 2)
 				ratr_bitmap &= 0x0007f000;
 			else
-				ratr_bitmap &= 0x0007f005;
+				ratr_bitmap &= 0x000fffff;
 		} else {
 			if (rtlphy->rf_type == RF_1T2R ||
 			    rtlphy->rf_type == RF_1T1R) {
@@ -932,14 +932,14 @@ static void rtl92d_update_hal_rate_mask(struct ieee80211_hw *hw,
 					else if (rssi_level == 2)
 						ratr_bitmap &= 0x000ff000;
 					else
-						ratr_bitmap &= 0x000ff015;
+						ratr_bitmap &= 0x000fffff;
 				} else {
 					if (rssi_level == 1)
 						ratr_bitmap &= 0x000f0000;
 					else if (rssi_level == 2)
 						ratr_bitmap &= 0x000ff000;
 					else
-						ratr_bitmap &= 0x000ff005;
+						ratr_bitmap &= 0x000fffff;
 				}
 			} else {
 				if (curtxbw_40mhz) {
@@ -948,14 +948,14 @@ static void rtl92d_update_hal_rate_mask(struct ieee80211_hw *hw,
 					else if (rssi_level == 2)
 						ratr_bitmap &= 0x0f0ff000;
 					else
-						ratr_bitmap &= 0x0f0ff015;
+						ratr_bitmap &= 0x0fffffff;
 				} else {
 					if (rssi_level == 1)
 						ratr_bitmap &= 0x0f0f0000;
 					else if (rssi_level == 2)
 						ratr_bitmap &= 0x0f0ff000;
 					else
-						ratr_bitmap &= 0x0f0ff005;
+						ratr_bitmap &= 0x0fffffff;
 				}
 			}
 		}
-- 
2.53.0

RE: [PATCH rtw-next 5/5] wifi: rtlwifi: rtl8192d: let the firmware use all rates

[Ping-Ke Shih]

Ho Jie Feng <hjf3108@gmail.com> wrote:
> The rate mask is chosen based on rssi_level, however rssi_level
> is always 0, 

Should we fix it ?

> since:
> - for rtl8192de, call to rtl92d_dm_refresh_rate_adaptive_mask is
>   commented out and function is not implemented
> - for rtl8192du, it is also not called.
> 
> This makes the branch always choose less than optimal allowed MCS rates.
> Enable all the rates.
> 
> Test results (2.4 GHz):
>    before after
> TX 6.4    12.6

How about the rate before/after? I think the highest rate will be similar
or the same?

> RX 32.0   39.1

You change many rate masks for different wireless modes, so please provide
more experiments. Especially you need tests for a clean & noisy environments. 

> 
> Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
> ---
>  .../wireless/realtek/rtlwifi/rtl8192d/hw_common.c    | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> index cfefbe86380fbc..0c921c049b5178 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> @@ -903,7 +903,7 @@ static void rtl92d_update_hal_rate_mask(struct ieee80211_hw *hw,
>                 else if (rssi_level == 2)
>                         ratr_bitmap &= 0x00000ff0;
>                 else
> -                       ratr_bitmap &= 0x00000ff5;
> +                       ratr_bitmap &= 0x00000fff;

This mask means all 12 OFDM rates. I guess original design wants to select
higher rate quickly.

>                 break;
>         case WIRELESS_MODE_A:
>                 ratr_index = RATR_INX_WIRELESS_G;
> @@ -922,7 +922,7 @@ static void rtl92d_update_hal_rate_mask(struct ieee80211_hw *hw,
>                         else if (rssi_level == 2)
>                                 ratr_bitmap &= 0x0007f000;
>                         else
> -                               ratr_bitmap &= 0x0007f005;
> +                               ratr_bitmap &= 0x000fffff;

For N mode, it wants to jump to MCS rate quickly I guess.

>                 } else {
>                         if (rtlphy->rf_type == RF_1T2R ||
>                             rtlphy->rf_type == RF_1T1R) {

[...]

Re: [PATCH rtw-next 5/5] wifi: rtlwifi: rtl8192d: let the firmware use all rates

[Jie Feng]

On Mon, 9 Nov 2026 at 08:56, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Ho Jie Feng <hjf3108@gmail.com> wrote:
> > The rate mask is chosen based on rssi_level, however rssi_level
> > is always 0,
>
> Should we fix it ?
The vendor driver for rtl8192du also doesn't do the rssi_level update
It is not compiled due to the #if 0
https://github.com/lwfinger/rtl8192du/blob/master/hal/rtl8192d_dm.c#L2624
Therefore, I'm not sure if it is okay to port it over.

> > since:
> > - for rtl8192de, call to rtl92d_dm_refresh_rate_adaptive_mask is
> >   commented out and function is not implemented
> > - for rtl8192du, it is also not called.
> >
> > This makes the branch always choose less than optimal allowed MCS rates.
> > Enable all the rates.
> >
> > Test results (2.4 GHz):
> >    before after
> > TX 6.4    12.6
>
> How about the rate before/after? I think the highest rate will be similar
> or the same?
Highest rate will be similar, but I saw it using more intermediate rates.

> > RX 32.0   39.1
>
> You change many rate masks for different wireless modes, so please provide
> more experiments. Especially you need tests for a clean & noisy environments.
So this patch by itself is more of an RFC, and I might drop it in v2
if it changes
behaviour too much in different circumstances.

> >
> > Signed-off-by: Ho Jie Feng <hjf3108@gmail.com>
> > ---
> >  .../wireless/realtek/rtlwifi/rtl8192d/hw_common.c    | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> > b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> > index cfefbe86380fbc..0c921c049b5178 100644
> > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c
> > @@ -903,7 +903,7 @@ static void rtl92d_update_hal_rate_mask(struct ieee80211_hw *hw,
> >                 else if (rssi_level == 2)
> >                         ratr_bitmap &= 0x00000ff0;
> >                 else
> > -                       ratr_bitmap &= 0x00000ff5;
> > +                       ratr_bitmap &= 0x00000fff;
>
> This mask means all 12 OFDM rates. I guess original design wants to select
> higher rate quickly.
> ...
> For N mode, it wants to jump to MCS rate quickly I guess.
That makes sense, I will leave it out for v2.

> >                 } else {
> >                         if (rtlphy->rf_type == RF_1T2R ||
> >                             rtlphy->rf_type == RF_1T1R) {
>
> [...]
>
>

RE: [PATCH rtw-next 5/5] wifi: rtlwifi: rtl8192d: let the firmware use all rates

[Ping-Ke Shih]

Jie Feng <hjf3108@gmail.com> wrote:
> On Mon, 9 Nov 2026 at 08:56, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Ho Jie Feng <hjf3108@gmail.com> wrote:
> > > The rate mask is chosen based on rssi_level, however rssi_level
> > > is always 0,
> >
> > Should we fix it ?
> The vendor driver for rtl8192du also doesn't do the rssi_level update
> It is not compiled due to the #if 0
> https://github.com/lwfinger/rtl8192du/blob/master/hal/rtl8192d_dm.c#L2624
> Therefore, I'm not sure if it is okay to port it over.

Add to your todo list. To fine tune throughput, you need a set of plan to
verify to ensure your implementation is good.

> 
> > > since:
> > > - for rtl8192de, call to rtl92d_dm_refresh_rate_adaptive_mask is
> > >   commented out and function is not implemented
> > > - for rtl8192du, it is also not called.
> > >
> > > This makes the branch always choose less than optimal allowed MCS rates.
> > > Enable all the rates.
> > >
> > > Test results (2.4 GHz):
> > >    before after
> > > TX 6.4    12.6
> >
> > How about the rate before/after? I think the highest rate will be similar
> > or the same?
> Highest rate will be similar, but I saw it using more intermediate rates.

With longer test time (e.g. 10 minutes), will throughput become similar?

> 
> > > RX 32.0   39.1
> >
> > You change many rate masks for different wireless modes, so please provide
> > more experiments. Especially you need tests for a clean & noisy environments.
> So this patch by itself is more of an RFC, and I might drop it in v2
> if it changes
> behaviour too much in different circumstances.

Yes, I think so. 

If you can make plans to verify it fully, I can accept the change.