From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=54.38.221.178 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794615607; b=3eXz+vdGkXuiGvWwiwOkFn3/J6Vx6SAMuxZmQMI9ClO7uwGq9gpsAOvAgLyN0DIponAc H818dmMhrxZn5E9io5L1QwK0fXAl3xRJGt4xvPow8jwKAHCcCE09H3bpy98qNieRmvqlk uoRz3PSdB0hhOd2ACgRA4GRSPnDIonvMn7+wh6okso3c8JuglbXwWdDDfDFAcgeD3kwHq Lys+MXD9eE+e4Wp5xIxbwzAbHtEuQ/aFRZHEl9rxAhp9VWCm5Dk3RdSCgJ6N5/X9vRFHF R1ZWIJCOESwMNHZmlL0HA7zs4oK5PZv2vUKtshxhopOI4YkwV3eTqPjsSpMRrCSw4Cw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794615607; h=DMARC-Filter:DKIM-Signature:Received:From:To:Cc:Subject:Date: Message-Id:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=uSNvE51YLCC+biUbP4t29+d0gpTTp78rVRLe4Op4Wsg=; b=CWz36linzaeidsKtDSKw1xe21ZRCBcwCoMWRdTpsjddCKrmd2ThlgPPi2IPeAH1ukKCq JxstQch1HKaF4QlamTZInMOXb7onJ8kT1KIQeyW+xKZl+aVxTqfY8ILpKV4pPNr9EHtib hPV0sZL/PQLU8q8Y5rYOyaPfzsxJMZOXw78FsOvHZdEb5eYwQviIqbFzLOaehuPkd1n3e dZi7MQcvI3m3SOc7mGrSEyaAJbRV3Bd/1tisYJ5sH3HM35r4NyfgoTMyh+nY0DC4h9Dt0 rILh8ZRAM++prQFjYKkFz+IjlFVmeyANUsTjHZrJSFS+7adlgPtaWKOBSeZUJs2tXHw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=loljews.com; spf=pass smtp.mailfrom=loljews.com; dkim=pass header.d=loljews.com header.i=@loljews.com header.a=rsa-sha256 header.s=mail header.b=bYymQIOK; arc=none smtp.remote-ip=54.38.221.178 Received: from mnc015mcc432.ss7-reroute.local (unknown [54.38.221.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0449606A336; Sat, 14 Nov 2026 00:20:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org B0449606A336 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=loljews.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loljews.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=loljews.com header.i=@loljews.com header.a=rsa-sha256 header.s=mail header.b=bYymQIOK DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loljews.com; s=mail; t=1794615596; bh=uSNvE51YLCC+biUbP4t29+d0gpTTp78rVRLe4Op4Wsg=; h=From:To:Cc:Subject:Date; b=bYymQIOKRIW7N9QQo4PPRd9EdoaTsumVJ8QTwEVt7Q/J7ym45iSFw/gCGv5KqfE00 6OA/o+ADYCAmkFrIUiW2wBMwll21O81+EKQG7409L3rfCQ7kOPGB6jVFY5AIYrk+Z/ KS7T0uYycdVNhK4Ru4HNaQB43RJzV41kw08xt7Z3q4Agv5ovzzcMKcWlRuYafJ/GyH XJrQ5cWJXLhr34fHwGLrKHki3kZl2q7Em6zdpHDkLuymgithCAx05GFIbWw2tNjtNC ehWRxRy2kPgyKAv9QdEYFkwXm4JTxChgFGBGQEAc75aAbtH8xz/GVNqzGGDHpQ7/Nk BlR8zwNs/xEqA== Received: from loljews.com (localhost [127.0.0.1]) by postfix (Postfix) with ESMTP id 498F027A347E; Sat, 14 Nov 2026 02:19:56 +0200 (EET) From: Sandeep Haemoon To: netdev@vger.kernel.org Cc: Felix Fietkau , Lorenzo Bianconi , Andrew Lunn , David S. Miller , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , Russell King , Daniel Golle , Mason Chang , Frank Wunderlich , linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next v5 0/3] net: ethernet: mtk_eth_soc: 9K jumbo frame support Date: Sat, 14 Nov 2026 00:45:24 +0200 Message-Id: X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This series makes the MediaTek SoC ethernet driver support 9K jumbo frames on the 10G XGMII MACs (MT7988). The driver advertises a 2030-byte max_mtu and programs the MAC max-rx field for at most 2048 bytes, so MTU > 2K is rejected and 9K frames are not usable. Patch 1 fixes a pre-existing 36-bit DMA bug in mtk_poll_rx() that the review of v3 found: a descriptor released without a new mapping is handed back with the previous buffer's high address bits. It is independent of the rest of the series and carries a Fixes: tag for the commit that introduced the bug, so the maintainers can route it to net directly if they prefer. Patch 2 gates the page_pool on the ring's descriptor length: the pool hands out order-0 pages and maps at most MTK_PP_MAX_BUF_SIZE, so a ring whose descriptor length is larger has to use the netdev_alloc_frag()/mtk_max_buf_alloc() path. Patch 3 adds the MTK_NETSYS_RX_9K capability, advertises a 9194-byte max_mtu on the XGMII MACs (from the DT phy_mode at probe, so DSA can raise the conduit MTU before the netdev is opened), programs XMAC_RX_CFG2 and the PDMA RX SDL, derives the shared RX buffer length from the largest MTU (802.1Q headroom included) and sizes the RX rings from it, keeping the never-polled QDMA ring at its 2K buffers. The MAC max-rx limits stay in sync with that shared length, including GMAC1's MCR jumbo field. A runtime MTU change that needs larger buffers is rejected with -EBUSY while DMA is running; shrinking is allowed. GMAC1, the built-in switch port, keeps its MCR programming (bucket plus the jumbo field in 1024-byte units), written after the MAC_MCR_FORCE_LINK_DOWN reset so it survives every mac_config(); whether the internal switch path enforces that field at all is a hardware property the commit message documents. This work is a forward-port of the MediaTek downstream jumbo work: Mason Chang's "change default rx buffer length" and "add 9k jumbo frame support" (MediaTek OpenWrt feed 999-eth-30/31, carried in frank-w/BPI-Router-Linux), plus Frank Wunderlich's "try to fix crash the right way". The runtime reallocation of Mason's "dynamic rx buffer adjustment" (feed 999-eth-33) is not included and will be sent separately. Attribution is prose plus Link: tags: Co-developed-by requires the original authors' own Signed-off-by lines, which we do not have, and the port diverges from the downstream implementation (2K buffer floor, per-ring pool gate, the -EBUSY rule, the XDP checks and the truesize fix are not in the downstream patches). The equivalent change was tested on a BPI-R4 Pro 8X (MT7988, 10G lan6 / MxL86252) on the 6.18.60 backport: with both ends at MTU 9000, 8K ICMP passes and iperf3 with MSS 8900 reaches ~9.87 Gbit/s (vs ~2.57 Gbit/s at MSS 1460); the DSA conduit is raised to 9004 at boot. This v7.3 series is compile-tested with CONFIG_NET_MEDIATEK_SOC=y and COMPILE_TEST=y; no hardware run of this exact tree yet. With the 1 KiB rounding the RX buffer length is order-1 (8 KiB) for rx_buf_len 4096..7168 and order-2 (16 KiB) from rx_buf_len 8192 up; at the 9K ring size the 16 KiB buffers pin around 64 MiB while DMA is up and make the refill a high-order GFP_ATOMIC allocation. That cost is inherent to the downstream design; skb->truesize now reports the allocation that was actually made. Changes in v5 (the v4 review, in full): - 802.1Q headroom (Medium): the shared RX buffer length now includes VLAN_HLEN before the 1 KiB round-up, and the advertised max_mtu is lowered by the same four bytes to 9194, so a tagged maximum-size frame (9194 + 18 + 4) still fits in rx_buf_len 9216 and the XMAC 9216 cap. XMAC_RX_CFG2 and the ring buffers therefore cover a tagged frame at every MTU, including the maximum. - GMAC1 MCR jumbo field (Medium): the vendor driver has a second MCR max-rx field we had not ported. mtk_set_mcr_max_rx() now clears and programs the jumbo field (bits 31:28, 1024-byte units, MAC_MCR_MAX_RX_JUMBO) for GMAC1, so the driver can program the same shared length for the switch port as for the XGMII MACs. The new field handling is limited to the MTK_NETSYS_RX_9K SoCs; every other SoC keeps its previous MCR programming bit for bit. - QDMA ring sizing (Medium): the helpers now take the buffer length instead of struct mtk_eth, and mtk_rx_alloc() sizes the never-polled QDMA RX ring at the fixed 2K length instead of the jumbo length, so it no longer pins ~32 MiB of high-order pages. HW-LRO rings keep their 12288-byte sizing. - pktlen bound (Medium): mtk_poll_rx() drops descriptors whose PLEN0 exceeds ring->buf_size, with rx_length_errors, before the buffer can be passed up, so the larger build_skb() size can no longer hand stale memory to the stack if the engine over-reports the length. - PDMA SDL encoding (Medium): kept as in v4; the comment and commit message now say explicitly that the GENMASK(30,16) encoding (frame length offset by MTK_PDMA_LRO_SDL) is the vendor's and not publicly documented, and that a datasheet confirmation would be welcome. - XDP detach (Medium): the pool-size check now runs only when a program is attached, so a detach always succeeds. The shared eth->prog weakness the review also points out is pre-existing and is left to a separate fix. - 3/3 message (Low): the buffer-size math is corrected (order-1 for rx_buf_len 4096..7168, order-2 from 8192) and the message now says that the build_skb()/truesize change also covers the HW-LRO rings on mt2701, mt7622, mt7623 and mt7629. - 1/3 subject and message (Low): retitled to describe the fix ("fix the RX descriptor address on the release path") and the message now cites 6e0490fc36cd and e10a35abb3da, which moved the DMA_MAPPING_ERROR initialisation out of the loop and made the first commit's protection ineffective after the first iteration. The pre-existing High finding of the review (a failure while filling an RX ring leaks the partially filled buffers and DMA mappings because ring->dma_size is still 0) is not part of this series: it is in the untouched v7.3 code and will be sent as a separate fix that sets ring->dma_size before the fill loop. Simon Horman's Reviewed-by is kept on patch 2 only: patches 1 and 3 are new or changed materially since his review of v1. Previous versions: https://lore.kernel.org/all/patch-fc08a7ef40667bf3017366e452e6d3c0@loljews.com/ (v4) https://lore.kernel.org/all/patch-aad4cfa8d9522d1f7dbc9893ea12e813@loljews.com/ (v3) https://lore.kernel.org/all/patch-2793186c653124c4c0b3d463bde2ea3a@loljews.com/ (v2) https://lore.kernel.org/all/patch-4f863a941889f0bceca1c082f2d79624@loljews.com/ (v1) Sandeep Haemoon (3): net: ethernet: mtk_eth_soc: fix the RX descriptor address on the release path net: ethernet: mtk_eth_soc: skip page_pool for RX rings whose buffers do not fit net: ethernet: mtk_eth_soc: add 9K jumbo frame support drivers/net/ethernet/mediatek/mtk_eth_soc.c | 324 ++++++++++++++++---- drivers/net/ethernet/mediatek/mtk_eth_soc.h | 16 +- 2 files changed, 282 insertions(+), 58 deletions(-) base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222 -- 2.53.0