[PATCH net-next v2 0/2] net: stmmac: dwmac-sun8i: Jumbo frames and an RX_TH fix

[PATCH net-next v2 0/2] net: stmmac: dwmac-sun8i: Jumbo frames and an RX_TH fix

[Arun Iyengar via B4 Relay]

The sun8i EMAC advertises a maximum MTU of 3712, but drops every frame
longer than 1518 bytes. Patch 2 sets the receiver's jumbo frame enable
bit and limits the MTU to what fits in one normal descriptor buffer
(2018). Patch 1 corrects two swapped RX threshold values; no in-tree
Allwinner board uses RX threshold mode, so none is affected.

Tested on an Orange Pi Zero2 (H616, RTL8211F over RGMII) at 1 Gbit/s,
with a 7.3 kernel carrying both patches:
- MTU 2000 and 2018: pings with DF set up to the full MTU pass in both
  directions, iperf3 gives 955 Mbit/s to the board and 905 Mbit/s from
  it, and the rx_length and rx_crc_errors counters stay at 0.
- Setting MTU 2019 is refused.
- At MTU 1500, a 90 minute run (bulk transfers up to 256 MiB both ways,
  iperf3 853/873 Mbit/s, 1000 pings each of 56, 1472 and 8000 bytes)
  had no loss and no new error counters.

In that 7.3 kernel, frames longer than 2044 bytes were dropped by a
local norm_desc change; v7.4-rc2 does the same through commit
834ec9530832 ("net: stmmac: drop split frames on AF_XDP zero-copy RX"),
which patch 2 now relies on.

These patches were developed with Claude (Anthropic) as a coding
assistant. It investigated the problem and wrote the code and the commit
messages; I reviewed them, and they were tested on an Orange Pi Zero2
(H616) as described above.

---
Changes in v2:
- Patch 1: add the Fixes: tag, and correct the commit message: RX
  threshold mode depends on snps,force_thresh_dma_mode, not on RX
  checksum offload (Sashiko AI review)
- Cc Corentin Labbe (author of the Fixes: target)
- Rebased onto current net-next; patch 2 unchanged
- Link to v1: https://patch.msgid.link/20261110-sun8i-emac-jumbo-v1-0-84bf00e9ffa3@gmail.com

---
Arun Iyengar (2):
      net: stmmac: dwmac-sun8i: Fix the RX_TH threshold encoding
      net: stmmac: dwmac-sun8i: Enable jumbo frames up to MTU 2018

 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 29 +++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)
---
base-commit: c88fd6989aea9237a60a4859139a265bfb7ddc0b
change-id: 20261110-sun8i-emac-jumbo-4839f984a6a9

Best regards,
--  
Arun Iyengar <aiyengar1990@gmail.com>

[PATCH net-next v2 1/2] net: stmmac: dwmac-sun8i: Fix the RX_TH threshold encoding

[Arun Iyengar via B4 Relay]

From: Arun Iyengar <aiyengar1990@gmail.com>

The EMAC RX_CTL1 RX_TH field (bits 5:4) encodes 00 = 64 bytes and
01 = 32 bytes (H616 user manual v1.0, 6.5.10; 10 = 96 and 11 = 128 bytes
as in the driver). The driver has the first two swapped.

The values are only used in RX threshold mode, which stmmac selects only
when the snps,force_thresh_dma_mode property is set. No Allwinner device
tree sets it, so no in-tree board is affected.

Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 47954537b29e..0c82662fbe6e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -198,8 +198,9 @@ static const struct emac_variant emac_variant_h616_emac1 = {
 /* Used in RX_CTL1*/
 #define EMAC_RX_MD              BIT(1)
 #define EMAC_RX_TH_MASK		GENMASK(5, 4)
-#define EMAC_RX_TH_32		0
-#define EMAC_RX_TH_64		(0x1 << 4)
+/* RX_CTL1 RX_TH encoding (H616 UM 6.5.10): 00 = 64, 01 = 32 bytes */
+#define EMAC_RX_TH_32		(0x1 << 4)
+#define EMAC_RX_TH_64		0
 #define EMAC_RX_TH_96		(0x2 << 4)
 #define EMAC_RX_TH_128		(0x3 << 4)
 #define EMAC_RX_DMA_EN  BIT(30)

-- 
2.55.0

Re: [PATCH net-next v2 1/2] net: stmmac: dwmac-sun8i: Fix the RX_TH threshold encoding

[Nicolai Buchwitz]

On 12.11.2026 09:41, Arun Iyengar via B4 Relay wrote:
> From: Arun Iyengar <aiyengar1990@gmail.com>
> 
> The EMAC RX_CTL1 RX_TH field (bits 5:4) encodes 00 = 64 bytes and
> 01 = 32 bytes (H616 user manual v1.0, 6.5.10; 10 = 96 and 11 = 128 
> bytes
> as in the driver). The driver has the first two swapped.
> 
> The values are only used in RX threshold mode, which stmmac selects 
> only
> when the snps,force_thresh_dma_mode property is set. No Allwinner 
> device
> tree sets it, so no in-tree board is affected.
> 
> Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
> Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index 47954537b29e..0c82662fbe6e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -198,8 +198,9 @@ static const struct emac_variant 
> emac_variant_h616_emac1 = {
>  /* Used in RX_CTL1*/
>  #define EMAC_RX_MD              BIT(1)
>  #define EMAC_RX_TH_MASK		GENMASK(5, 4)
> -#define EMAC_RX_TH_32		0
> -#define EMAC_RX_TH_64		(0x1 << 4)
> +/* RX_CTL1 RX_TH encoding (H616 UM 6.5.10): 00 = 64, 01 = 32 bytes */
> +#define EMAC_RX_TH_32		(0x1 << 4)
> +#define EMAC_RX_TH_64		0
>  #define EMAC_RX_TH_96		(0x2 << 4)
>  #define EMAC_RX_TH_128		(0x3 << 4)
>  #define EMAC_RX_DMA_EN  BIT(30)

Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>

Thanks,
Nicolai

Re: [PATCH net-next v2 1/2] net: stmmac: dwmac-sun8i: Fix the RX_TH threshold encoding

[Chen-Yu Tsai]

On Thu, Nov 12, 2026 at 5:41 PM Arun Iyengar via B4 Relay
<devnull+aiyengar1990.gmail.com@kernel.org> wrote:
>
> From: Arun Iyengar <aiyengar1990@gmail.com>
>
> The EMAC RX_CTL1 RX_TH field (bits 5:4) encodes 00 = 64 bytes and
> 01 = 32 bytes (H616 user manual v1.0, 6.5.10; 10 = 96 and 11 = 128 bytes
> as in the driver). The driver has the first two swapped.
>
> The values are only used in RX threshold mode, which stmmac selects only
> when the snps,force_thresh_dma_mode property is set. No Allwinner device
> tree sets it, so no in-tree board is affected.
>
> Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
> Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>

Reviewed-by: Chen-Yu Tsai <wens@kernel.org>

Checked A64, H3, H6 user manuals as well.

The original chip this came in, the A83T, the manual for it doesn't have
the bits for this register.

[PATCH net-next v2 2/2] net: stmmac: dwmac-sun8i: Enable jumbo frames up to MTU 2018

[Arun Iyengar via B4 Relay]

From: Arun Iyengar <aiyengar1990@gmail.com>

The sun8i EMAC advertises a maximum MTU of 3712, but no frame larger
than the standard 1518 bytes is actually received: on an H616 board
(Orange Pi Zero2, RTL8211F over RGMII) every ping above 1472 bytes with
DF set is lost, and the rx_length counter goes up for each one.

There are two independent limits:

1. EMAC_RX_CTL0 bit 29 (JUMBO_FRM_EN) is never set, so the receiver
   rejects frames longer than 1518 (1522 with a VLAN tag) bytes. The
   Allwinner BSP driver (sunxi-gmac) sets this bit unconditionally at
   init. Set it in core_init as well; core_init runs after every DMA
   soft reset, including the one done by an MTU change.

2. The EMAC has no Synopsys HW feature register, so stmmac uses normal
   descriptors in chain mode and, without enh_desc, sets max_mtu to
   SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN), which is 3712 with 4K
   pages. That value is not a hardware limit. The descriptor buffer
   size field is 11 bits wide (the same in the BSP and the QEMU model),
   so ndesc_init_rx_desc() caps each RX buffer at 2047 bytes, and
   ndesc_get_rx_status() discards any frame that needs a second
   descriptor. On TX, stmmac_xmit() only splits jumbo frames for
   enh_desc, and norm_set_tx_desc_len_on_chain() masks the length to
   11 bits, so a linear frame longer than 2047 bytes would be silently
   truncated.

Moreover, the RX DMA only fills a multiple of 4 bytes of a buffer: on
the H616, with 2047 programmed, a 2044 byte frame (FCS included) is
received in one descriptor and a 2045 byte frame already spills into a
second one. The usable size is therefore 2044 bytes, the same value as
DESC_BUF_MAX in the original sun8i-emac submission and in the U-Boot
driver.

Limit max_mtu so that a frame with two VLAN tags and the FCS fits in
2044 bytes (MTU 2018). A device tree max-frame-size can still lower it.
Longer frames from the wire span two descriptors and are dropped as a
whole by stmmac_rx(), which drains the descriptors of a split frame
since commit 834ec9530832 ("net: stmmac: drop split frames on AF_XDP
zero-copy RX").

Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 24 +++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 0c82662fbe6e..a18d3daf6a3f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/if_vlan.h>
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/mdio-mux.h>
@@ -219,12 +220,25 @@ static const struct emac_variant emac_variant_h616_emac1 = {
 
 /* Used in RX_CTL0 */
 #define EMAC_RX_RECEIVER_EN             BIT(31)
+#define EMAC_RX_JUMBO_FRM_EN		BIT(29)
 #define EMAC_RX_DO_CRC BIT(27)
 #define EMAC_RX_FLOW_CTL_EN             BIT(16)
 
 /* Used in TX_CTL0 */
 #define EMAC_TX_TRANSMITTER_EN  BIT(31)
 
+/* The buffer size field of the EMAC DMA descriptors is 11 bits wide, and
+ * the RX DMA only fills a multiple of 4 bytes of a buffer: with 2047
+ * programmed, frames longer than 2044 bytes spill into a second
+ * descriptor. The stmmac normal descriptor code used for this EMAC only
+ * handles frames that fit in a single RX descriptor and a single TX
+ * descriptor buffer. Bound the MTU so that a frame, including two VLAN
+ * tags and the FCS, always fits in 2044 bytes.
+ */
+#define EMAC_MAX_FRAME_LEN	2044
+#define EMAC_MAX_MTU		(EMAC_MAX_FRAME_LEN - ETH_HLEN - \
+				 2 * VLAN_HLEN - ETH_FCS_LEN)
+
 /* Used in EMAC_TX_FLOW_CTL */
 #define EMAC_TX_FLOW_CTL_EN             BIT(0)
 
@@ -645,6 +659,15 @@ static void sun8i_dwmac_core_init(struct mac_device_info *hw,
 
 	v = (8 << EMAC_BURSTLEN_SHIFT); /* burst len */
 	writel(v, ioaddr + EMAC_BASIC_CTL1);
+
+	/* Without JUMBO_FRM_EN the receiver flags every frame longer than
+	 * 1518 bytes (1522 with a VLAN tag) as a length error, so any MTU
+	 * above 1500 is unusable. Frames are still bounded by the RX
+	 * descriptor buffer size, see EMAC_MAX_MTU.
+	 */
+	v = readl(ioaddr + EMAC_RX_CTL0);
+	v |= EMAC_RX_JUMBO_FRM_EN;
+	writel(v, ioaddr + EMAC_RX_CTL0);
 }
 
 static void sun8i_dwmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -1209,6 +1232,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 	plat_dat->mac_setup = sun8i_dwmac_setup;
 	plat_dat->tx_fifo_size = 4096;
 	plat_dat->rx_fifo_size = 16384;
+	plat_dat->maxmtu = min(plat_dat->maxmtu, EMAC_MAX_MTU);
 
 	ret = sun8i_dwmac_set_syscon(&pdev->dev, plat_dat);
 	if (ret)

-- 
2.55.0

Re: [PATCH net-next v2 2/2] net: stmmac: dwmac-sun8i: Enable jumbo frames up to MTU 2018

[Nicolai Buchwitz]

Hi Arun

On 12.11.2026 09:41, Arun Iyengar via B4 Relay wrote:
> From: Arun Iyengar <aiyengar1990@gmail.com>

> [...]

> Limit max_mtu so that a frame with two VLAN tags and the FCS fits in
> 2044 bytes (MTU 2018). A device tree max-frame-size can still lower it.

max-frame-size is only parsed for the snps,dwmac compatibles, not for 
sun8i.

> [...]

Thanks,
Nicolai

Re: [PATCH net-next v2 2/2] net: stmmac: dwmac-sun8i: Enable jumbo frames up to MTU 2018

[Chen-Yu Tsai]

On Thu, Nov 12, 2026 at 5:41 PM Arun Iyengar via B4 Relay
<devnull+aiyengar1990.gmail.com@kernel.org> wrote:
>
> From: Arun Iyengar <aiyengar1990@gmail.com>
>
> The sun8i EMAC advertises a maximum MTU of 3712, but no frame larger
> than the standard 1518 bytes is actually received: on an H616 board
> (Orange Pi Zero2, RTL8211F over RGMII) every ping above 1472 bytes with
> DF set is lost, and the rx_length counter goes up for each one.
>
> There are two independent limits:
>
> 1. EMAC_RX_CTL0 bit 29 (JUMBO_FRM_EN) is never set, so the receiver
>    rejects frames longer than 1518 (1522 with a VLAN tag) bytes. The
>    Allwinner BSP driver (sunxi-gmac) sets this bit unconditionally at
>    init. Set it in core_init as well; core_init runs after every DMA
>    soft reset, including the one done by an MTU change.
>
> 2. The EMAC has no Synopsys HW feature register, so stmmac uses normal
>    descriptors in chain mode and, without enh_desc, sets max_mtu to

The hardware only supports normal descriptors, period.

>    SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN), which is 3712 with 4K
>    pages. That value is not a hardware limit. The descriptor buffer
>    size field is 11 bits wide (the same in the BSP and the QEMU model),
>    so ndesc_init_rx_desc() caps each RX buffer at 2047 bytes, and
>    ndesc_get_rx_status() discards any frame that needs a second
>    descriptor. On TX, stmmac_xmit() only splits jumbo frames for
>    enh_desc, and norm_set_tx_desc_len_on_chain() masks the length to
>    11 bits, so a linear frame longer than 2047 bytes would be silently
>    truncated.

If that's true, that sounds like a serious bug.

But that's just the limit of each descriptor. The stmmac driver already
has code for both chained and ring mode descriptors to split one fragment
across multiple descriptors for TX.

I think what should be done is just remove the "if (enh_desc)" check
before

    is_jumbo = priv->hw->mode->is_jumbo_frm(skb->len, enh_desc);

Now if the jumbo frame code is buggy (because no one ever ran into for
who knows how long), then that should be fixed.

> Moreover, the RX DMA only fills a multiple of 4 bytes of a buffer: on
> the H616, with 2047 programmed, a 2044 byte frame (FCS included) is
> received in one descriptor and a 2045 byte frame already spills into a
> second one. The usable size is therefore 2044 bytes, the same value as
> DESC_BUF_MAX in the original sun8i-emac submission and in the U-Boot
> driver.

And it also has code to deal with a frame spanning multiple descriptors
or buffers in the RX path. So if you say 2045 bytes is spilling over
to the next buffer, then the size limit for each descriptor's buffer
should be 2044.

I think this should be done somewhere in stmmac_setup_dma_desc() by
aligning bfsize or ultimately dma_conf->dma_buf_sz to a multiple of 4.

The limiting to 2047 bytes in ndesc_init_rx_desc() also seems suspect,
as the rest of the driver is not aware of this limiting, and would
likely cause misalignment or dropped bytes when reassembling a frame
from multiple descriptors.

> Limit max_mtu so that a frame with two VLAN tags and the FCS fits in
> 2044 bytes (MTU 2018). A device tree max-frame-size can still lower it.

So what you are doing is just papering over what is broken underneath.
Fix the actual problem so we can have MTU up to 9 KB.

> Longer frames from the wire span two descriptors and are dropped as a
> whole by stmmac_rx(), which drains the descriptors of a split frame
> since commit 834ec9530832 ("net: stmmac: drop split frames on AF_XDP
> zero-copy RX").

I doubt that's the case. This commit said it only covers AF_XDP, which
is not your normal network transfers.


ChenYu

> Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 24 +++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index 0c82662fbe6e..a18d3daf6a3f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -6,6 +6,7 @@
>   */
>
>  #include <linux/clk.h>
> +#include <linux/if_vlan.h>
>  #include <linux/io.h>
>  #include <linux/iopoll.h>
>  #include <linux/mdio-mux.h>
> @@ -219,12 +220,25 @@ static const struct emac_variant emac_variant_h616_emac1 = {
>
>  /* Used in RX_CTL0 */
>  #define EMAC_RX_RECEIVER_EN             BIT(31)
> +#define EMAC_RX_JUMBO_FRM_EN           BIT(29)
>  #define EMAC_RX_DO_CRC BIT(27)
>  #define EMAC_RX_FLOW_CTL_EN             BIT(16)
>
>  /* Used in TX_CTL0 */
>  #define EMAC_TX_TRANSMITTER_EN  BIT(31)
>
> +/* The buffer size field of the EMAC DMA descriptors is 11 bits wide, and
> + * the RX DMA only fills a multiple of 4 bytes of a buffer: with 2047
> + * programmed, frames longer than 2044 bytes spill into a second
> + * descriptor. The stmmac normal descriptor code used for this EMAC only
> + * handles frames that fit in a single RX descriptor and a single TX
> + * descriptor buffer. Bound the MTU so that a frame, including two VLAN
> + * tags and the FCS, always fits in 2044 bytes.
> + */
> +#define EMAC_MAX_FRAME_LEN     2044
> +#define EMAC_MAX_MTU           (EMAC_MAX_FRAME_LEN - ETH_HLEN - \
> +                                2 * VLAN_HLEN - ETH_FCS_LEN)
> +
>  /* Used in EMAC_TX_FLOW_CTL */
>  #define EMAC_TX_FLOW_CTL_EN             BIT(0)
>
> @@ -645,6 +659,15 @@ static void sun8i_dwmac_core_init(struct mac_device_info *hw,
>
>         v = (8 << EMAC_BURSTLEN_SHIFT); /* burst len */
>         writel(v, ioaddr + EMAC_BASIC_CTL1);
> +
> +       /* Without JUMBO_FRM_EN the receiver flags every frame longer than
> +        * 1518 bytes (1522 with a VLAN tag) as a length error, so any MTU
> +        * above 1500 is unusable. Frames are still bounded by the RX
> +        * descriptor buffer size, see EMAC_MAX_MTU.
> +        */
> +       v = readl(ioaddr + EMAC_RX_CTL0);
> +       v |= EMAC_RX_JUMBO_FRM_EN;
> +       writel(v, ioaddr + EMAC_RX_CTL0);
>  }
>
>  static void sun8i_dwmac_set_mac(void __iomem *ioaddr, bool enable)
> @@ -1209,6 +1232,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
>         plat_dat->mac_setup = sun8i_dwmac_setup;
>         plat_dat->tx_fifo_size = 4096;
>         plat_dat->rx_fifo_size = 16384;
> +       plat_dat->maxmtu = min(plat_dat->maxmtu, EMAC_MAX_MTU);
>
>         ret = sun8i_dwmac_set_syscon(&pdev->dev, plat_dat);
>         if (ret)
>
> --
> 2.55.0
>
>