[PATCH net-next] net/stmmac/dwxgmac: Extend MTL/DMA support to 16 queues

[PATCH net-next] net/stmmac/dwxgmac: Extend MTL/DMA support to 16 queues

[Sagar Cheluvegowda]

From: Jakub Raczynski <j.raczynski@samsung.com>

New datasheets for XGMAC (3.20a and 3.40a, depending on product)
support up to 16 MTL/DMA queues. Before we increase max amount
through macro, prepare dwxgmac functions to handle that.

Queue numbers above 15 are not valid for this hardware. Callers are
expected to bound them, so reaching the default case is a programming
error rather than a runtime condition. Use WARN_ON() for it instead
of a netdev_err() message: the callback has no net_device of its own,
and a message-only failure in a void callback is easy to miss, while a
warning with a backtrace points straight at the offending caller.

Co-developed-by: Chang-Sub Lee <cs0617.lee@samsung.com>
Signed-off-by: Chang-Sub Lee <cs0617.lee@samsung.com>
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
Co-developed-by: Sagar Cheluvegowda <sagar.cheluvegowda@oss.qualcomm.com>
Signed-off-by: Sagar Cheluvegowda <sagar.cheluvegowda@oss.qualcomm.com>
---
Patch 2/3 of Jakub's v2 series:
https://lore.kernel.org/netdev/20260601162537.553512-3-j.raczynski@samsung.com/

Jakub has confirmed he will not be continuing this series, so we are
posting this patch on its own. We need it for Qualcomm Nord, a
25GMAC-based SoC that implements 12 MTL/DMA queues. Jakub's authorship
and sign-offs are kept.

Changes vs v2 2/3:
- Replace the netdev_err() + return in the default case with
  WARN_ON() + return, following the review feedback on 1/3 against
  message-only failures in void callbacks.

Tested on Qualcomm Nord with 12 queues: the MAP0..MAP2 registers were
checked to hold the expected RX queue to DMA channel mapping. The MAP3
register (queues 12-15) is carried over unchanged from v2 and is not
exercised on that hardware.

This is needed for XGMAC-based hardware with more than 8 MTL/DMA
queues (Qualcomm Nord has 12).

 .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  2 ++
 .../ethernet/stmicro/stmmac/dwxgmac2_core.c   | 21 +++++++++++++++++--
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index f8ab347f7b5b..6d4affbd34a1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -257,6 +257,8 @@
 #define XGMAC_MTL_INT_STATUS		0x00001020
 #define XGMAC_MTL_RXQ_DMA_MAP0		0x00001030
 #define XGMAC_MTL_RXQ_DMA_MAP1		0x00001034
+#define XGMAC_MTL_RXQ_DMA_MAP2		0x00001038
+#define XGMAC_MTL_RXQ_DMA_MAP3		0x0000103c
 #define XGMAC_QxMDMACH(x)		GENMASK((x) * 8 + 7, (x) * 8)
 #define XGMAC_QxMDMACH_SHIFT(x)		((x) * 8)
 #define XGMAC_QDDMACH			BIT(7)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 1a88cbaed70c..563d29d72543 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -257,9 +257,26 @@ static void dwxgmac2_map_mtl_to_dma(struct mac_device_info *hw, u32 queue,
 	void __iomem *ioaddr = hw->pcsr;
 	u32 value, reg;
 
-	reg = (queue < 4) ? XGMAC_MTL_RXQ_DMA_MAP0 : XGMAC_MTL_RXQ_DMA_MAP1;
-	if (queue >= 4)
+	switch (queue) {
+	case 0 ... 3:
+		reg = XGMAC_MTL_RXQ_DMA_MAP0;
+		break;
+	case 4 ... 7:
+		reg = XGMAC_MTL_RXQ_DMA_MAP1;
 		queue -= 4;
+		break;
+	case 8 ... 11:
+		reg = XGMAC_MTL_RXQ_DMA_MAP2;
+		queue -= 8;
+		break;
+	case 12 ... 15:
+		reg = XGMAC_MTL_RXQ_DMA_MAP3;
+		queue -= 12;
+		break;
+	default:
+		WARN_ON(1);
+		return;
+	}
 
 	value = readl(ioaddr + reg);
 	value &= ~XGMAC_QxMDMACH(queue);
-- 
2.34.1

Re: [PATCH net-next] net/stmmac/dwxgmac: Extend MTL/DMA support to 16 queues

[Jakub Raczynski]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

On Fri, Oct 16, 2026 at 12:38:23PM -0700, Sagar Cheluvegowda wrote:
> From: Jakub Raczynski <j.raczynski@samsung.com>
> 
> Patch 2/3 of Jakub's v2 series:
> https://lore.kernel.org/netdev/20260601162537.553512-3-j.raczynski@samsung.com/
> 
> Jakub has confirmed he will not be continuing this series, so we are
> posting this patch on its own. We need it for Qualcomm Nord, a
> 25GMAC-based SoC that implements 12 MTL/DMA queues. Jakub's authorship
> and sign-offs are kept.
> 
> Changes vs v2 2/3:
> - Replace the netdev_err() + return in the default case with
>   WARN_ON() + return, following the review feedback on 1/3 against
>   message-only failures in void callbacks.
> 
> Tested on Qualcomm Nord with 12 queues: the MAP0..MAP2 registers were
> checked to hold the expected RX queue to DMA channel mapping. The MAP3
> register (queues 12-15) is carried over unchanged from v2 and is not
> exercised on that hardware.
> 
> This is needed for XGMAC-based hardware with more than 8 MTL/DMA
> queues (Qualcomm Nord has 12).
> 
>  .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  2 ++

Thanks for including me as signed-off.

But I am not sure I like this patch being sent on its own. I checked Sashiko
review on patchwork and there are no comments and that is actually (not)
impressive by Sashiko.
Issues I have are:
- Does it work if macro MTL_MAX_{TX/RX}_QUEUES is not increased?
- My patch 1/3 was doing some prep since new XGMAC have unique setup where
  number of DMA channels differ from number of TC's.

  How does it look like in your hardware? 12 DMA and (8 or 12) TC's?

  I agree with comment by Jakub Kicinski on my patchset 1/3 that I should have
  implemented it better, but never finally did. Issue is, stmmac driver
  assumes number of DMA = TC and uses {tx/rx}_queues_to_use everywhere.
  So proper implementation would be spliting DMA count and TC count,
  where both can be verified by stmmac_get_hw_features().

  Of course, above applies if DMA!=TC in your hardware.

BR
Jakub Raczynski

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH net-next] net/stmmac/dwxgmac: Extend MTL/DMA support to 16 queues

[Sagar Cheluvegowda]

Hi Jakub,

Apologies for the late reply, and thanks for the review.

> - Does it work if macro MTL_MAX_{TX/RX}_QUEUES is not increased?

No. With the macros at 8, the DT parser clamps snps,{rx,tx}-queues-to-use
to 8 and ignores the extra queue nodes, so queues 8-11 are never set up or
mapped. The patch has no effect until the macros are raised. Our 12-queue
testing was on a tree that also raises them, and my note under the "---"
should have said so. You are right that it should not go out on its own.

>   How does it look like in your hardware? 12 DMA and (8 or 12) TC's?

The Nord hardware supports 16 queues, but only 12 are enabled in our SoC.
It has 8 TCs, so DMA != TC here too.

>
>   I agree with comment by Jakub Kicinski on my patchset 1/3 that I should have
>   implemented it better, but never finally did. Issue is, stmmac driver
>   assumes number of DMA = TC and uses {tx/rx}_queues_to_use everywhere.
>   So proper implementation would be spliting DMA count and TC count,
>   where both can be verified by stmmac_get_hw_features().

Agreed. I went through your 1/3 against the databook. One point on flow
control: XGMAC_Qx_TX_FLOW_CTRL(i) and the PSRQ(i) fields exist only for
i = 0..7, since PFC is per 802.1Q priority, and 0x90..0x98 is RX_FLOW_CTRL /
MAC_RxQ_Ctrl4/5. Bounding dwxgmac2_flow_ctrl() by numtc is therefore not the
right limit: it happens to be correct for 8 TCs, but wrong where numtc < 8,
and it should be a fixed 8 (the PSRQ window; MAC_RxQ_Ctrl5.PRQSO can shift
that window).
I will review the whole series thoroughly and pick it up after testing it
internally on Nord. I will keep your authorship and sign-offs on the parts
that come from your patches.

Thanks,
Sagar