[PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Yao Zi]

This series adds glue driver for Motorcomm YT6801 PCIe ethernet
controller, which is considered mostly compatible with DWMAC-4 IP by
inspecting the register layout[1]. It integrates a Motorcomm YT8531S PHY
(confirmed by reading PHY ID) and GMII is used to connect the PHY to
MAC[2].

The initialization logic of the MAC is mostly based on previous upstream
effort for the controller[3] and the Deepin-maintained downstream Linux
driver[4] licensed under GPL-2.0 according to its SPDX headers. However,
this series is a completely re-write of the previous patch series,
utilizing the existing DWMAC4 driver and introducing a glue driver only.

This series only aims to add basic networking functions for the
controller, features like WoL, RSS and LED control are omitted for now.
Testing is done on i3-4170, it reaches 939Mbps (TX)/933Mbps (RX) on
average,

YT6801 TX

Connecting to host 192.168.114.51, port 5201
[  5] local 192.168.114.50 port 52986 connected to 192.168.114.51 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   112 MBytes   938 Mbits/sec    0    950 KBytes
[  5]   1.00-2.00   sec   113 MBytes   949 Mbits/sec    0   1.08 MBytes
[  5]   2.00-3.00   sec   112 MBytes   938 Mbits/sec    0   1.08 MBytes
[  5]   3.00-4.00   sec   111 MBytes   932 Mbits/sec    0   1.13 MBytes
[  5]   4.00-5.00   sec   113 MBytes   945 Mbits/sec    0   1.13 MBytes
[  5]   5.00-6.00   sec   112 MBytes   936 Mbits/sec    0   1.13 MBytes
[  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec    0   1.19 MBytes
[  5]   7.00-8.00   sec   112 MBytes   935 Mbits/sec    0   1.19 MBytes
[  5]   8.00-9.00   sec   113 MBytes   948 Mbits/sec    0   1.19 MBytes
[  5]   9.00-10.00  sec   111 MBytes   931 Mbits/sec    0   1.19 MBytes

YT6801 RX

Connecting to host 192.168.114.50, port 5201
[  5] local 192.168.114.51 port 41578 connected to 192.168.114.50 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   944 Mbits/sec    0    542 KBytes
[  5]   1.00-2.00   sec   111 MBytes   934 Mbits/sec    0    850 KBytes
[  5]   2.00-3.00   sec   111 MBytes   933 Mbits/sec    0   1.01 MBytes
[  5]   3.00-4.00   sec   112 MBytes   943 Mbits/sec    0   1.01 MBytes
[  5]   4.00-5.00   sec   111 MBytes   932 Mbits/sec    0   1.01 MBytes
[  5]   5.00-6.00   sec   111 MBytes   929 Mbits/sec    0   1.01 MBytes
[  5]   6.00-7.00   sec   112 MBytes   937 Mbits/sec    0   1.01 MBytes
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec    0   1.01 MBytes
[  5]   8.00-9.00   sec   111 MBytes   929 Mbits/sec    0   1.01 MBytes
[  5]   9.00-10.00  sec   111 MBytes   932 Mbits/sec    0   1.01 MBytes

My mail provider failed to deliver the original v6 series to the list,
sorry for the inconvenience. Thanks for your time and review.

[1]: https://lore.kernel.org/all/Z_T6vv013jraCzSD@shell.armlinux.org.uk/
[2]: https://lore.kernel.org/all/a48d76ac-db08-46d5-9528-f046a7b541dc@motor-comm.com/
[3]: https://lore.kernel.org/all/a48d76ac-db08-46d5-9528-f046a7b541dc@motor-comm.com/
[4]: https://github.com/deepin-community/kernel/tree/dc61248a0e21/drivers/net/ethernet/motorcomm/yt6801

Changed from v5
- PATCH 1: Collect review tags
- PATCH 2: Remove struct device from dwmac_motorcomm_priv, since it's
           only used during probe.
- Link to v5: https://lore.kernel.org/netdev/20251225071914.1903-1-me@ziyao.cc/

Changed from v4
- PATCH 1: don't set RGMII delay register in GMII mode
- PATCH 2
  - Disable ASPM L1 link state to work around problematic PCIe addon
    cards
  - Don't use an extra buffer when reading eFuse patches
  - Call eth_random_addr() directly when generating a random MAC is
    necessary
  - Drop unused register field definitions
  - Fix indentation for interrupt-moderation-related field definitions
- Link to v4: https://lore.kernel.org/all/20251216180331.61586-1-me@ziyao.cc/

Changed from v3
- Manually register a devres action to call pci_free_irq_vectors(),
  instead of relying on the obsolete behavior of
  pci_alloc_irq_vectors().
- Remove redundant call to pci_free_irq_vectors() in remove callback.
- Use my new mail address me@ziyao.cc for Sign-off-by and commit author.
- Link to v3: https://lore.kernel.org/netdev/20251124163211.54994-1-ziyao@disroot.org/

Changed from v2
- Rebase on top of next-20251124
- Switch to stmmac_plat_dat_alloc() then drop now redundant parameters
  from motorcomm_default_plat_data()
- Set STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP
- Add a comment indicating the possible source of CSR clock
- Link to v2: https://lore.kernel.org/netdev/20251111105252.53487-1-ziyao@disroot.org/

Changed from v1
- Drop (original) PATCH 1, add no vendor ID entry to linux/pci_ids.h
- Use PHY_INTERFACE_MODE_GMII instead of PHY_INTERFACE_MODE_INTERNAL
- Drop extra register read in motorcomm_efuse_read_byte()
- Rename EPHY_RESET to EPHY_MDIO_PHY_RESET, add a comment to reflect its
  function better
- Use the newly-introduced generic PCI suspend/resume routines
- Generate a random MAC address instead of failing to probe when no MAC
  address is programmed in eFuse (seen on some OEM EVBs).
- Collect Tested-by tags
- Link to v1: https://lore.kernel.org/netdev/20251014164746.50696-2-ziyao@disroot.org/

Yao Zi (3):
  net: phy: motorcomm: Support YT8531S PHY in YT6801 Ethernet controller
  net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller
  MAINTAINERS: Assign myself as maintainer of Motorcomm DWMAC glue
    driver

 MAINTAINERS                                   |   6 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |   9 +
 drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
 .../ethernet/stmicro/stmmac/dwmac-motorcomm.c | 384 ++++++++++++++++++
 drivers/net/phy/motorcomm.c                   |   4 +
 5 files changed, 404 insertions(+)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c

-- 
2.52.0

[PATCH RESEND net-next v6 1/3] net: phy: motorcomm: Support YT8531S PHY in YT6801 Ethernet controller

[Yao Zi]

YT6801's internal PHY is confirmed as a GMII-capable variant of YT8531S
by a previous series[1] and reading PHY ID. Add support for
PHY_INTERFACE_MODE_GMII for YT8531S to allow the Ethernet driver to
reuse the PHY code for its internal PHY.

Link: https://lore.kernel.org/all/a48d76ac-db08-46d5-9528-f046a7b541dc@motor-comm.com/ # [1]
Co-developed-by: Frank Sae <Frank.Sae@motor-comm.com>
Signed-off-by: Frank Sae <Frank.Sae@motor-comm.com>
Signed-off-by: Yao Zi <me@ziyao.cc>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/net/phy/motorcomm.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c
index 89b5b19a9bd2..dc9569a39cb4 100644
--- a/drivers/net/phy/motorcomm.c
+++ b/drivers/net/phy/motorcomm.c
@@ -910,6 +910,10 @@ static int ytphy_rgmii_clk_delay_config(struct phy_device *phydev)
 		val |= FIELD_PREP(YT8521_RC1R_RX_DELAY_MASK, rx_reg) |
 		       FIELD_PREP(YT8521_RC1R_GE_TX_DELAY_MASK, tx_reg);
 		break;
+	case PHY_INTERFACE_MODE_GMII:
+		if (phydev->drv->phy_id != PHY_ID_YT8531S)
+			return -EOPNOTSUPP;
+		return 0;
 	default: /* do not support other modes */
 		return -EOPNOTSUPP;
 	}
-- 
2.52.0

Re: [PATCH RESEND net-next v6 1/3] net: phy: motorcomm: Support YT8531S PHY in YT6801 Ethernet controller

[Russell King (Oracle)]

On Fri, Jan 09, 2026 at 09:34:44AM +0000, Yao Zi wrote:
> YT6801's internal PHY is confirmed as a GMII-capable variant of YT8531S
> by a previous series[1] and reading PHY ID. Add support for
> PHY_INTERFACE_MODE_GMII for YT8531S to allow the Ethernet driver to
> reuse the PHY code for its internal PHY.
> 
> Link: https://lore.kernel.org/all/a48d76ac-db08-46d5-9528-f046a7b541dc@motor-comm.com/ # [1]
> Co-developed-by: Frank Sae <Frank.Sae@motor-comm.com>
> Signed-off-by: Frank Sae <Frank.Sae@motor-comm.com>
> Signed-off-by: Yao Zi <me@ziyao.cc>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Thanks!

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

[PATCH RESEND net-next v6 2/3] net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller

[Yao Zi]

Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
integrates an GbE phy, supporting WOL, VLAN tagging and various types
of offloading. It ships an on-chip eFuse for storing various vendor
configuration, including MAC address.

This patch adds basic glue code for the controller, allowing it to be
set up and transmit data at a reasonable speed. Features like WOL could
be implemented in the future.

Signed-off-by: Yao Zi <me@ziyao.cc>
Tested-by: Mingcong Bai <jeffbai@aosc.io>
Tested-by: Runhua He <hua@aosc.io>
Tested-by: Xi Ruoyao <xry111@xry111.site>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig   |   9 +
 drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
 .../ethernet/stmicro/stmmac/dwmac-motorcomm.c | 384 ++++++++++++++++++
 3 files changed, 394 insertions(+)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 907fe2e927f0..07088d03dbab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -374,6 +374,15 @@ config DWMAC_LOONGSON
 	  This selects the LOONGSON PCI bus support for the stmmac driver,
 	  Support for ethernet controller on Loongson-2K1000 SoC and LS7A1000 bridge.
 
+config DWMAC_MOTORCOMM
+	tristate "Motorcomm PCI DWMAC support"
+	depends on PCI
+	select MOTORCOMM_PHY
+	select STMMAC_LIBPCI
+	help
+	  This enables glue driver for Motorcomm DWMAC-based PCI Ethernet
+	  controllers. Currently only YT6801 is supported.
+
 config STMMAC_PCI
 	tristate "STMMAC PCI bus support"
 	depends on PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 7bf528731034..c9263987ef8d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -48,4 +48,5 @@ obj-$(CONFIG_STMMAC_LIBPCI)	+= stmmac_libpci.o
 obj-$(CONFIG_STMMAC_PCI)	+= stmmac-pci.o
 obj-$(CONFIG_DWMAC_INTEL)	+= dwmac-intel.o
 obj-$(CONFIG_DWMAC_LOONGSON)	+= dwmac-loongson.o
+obj-$(CONFIG_DWMAC_MOTORCOMM)	+= dwmac-motorcomm.o
 stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
new file mode 100644
index 000000000000..8b45b9cf7202
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * DWMAC glue driver for Motorcomm PCI Ethernet controllers
+ *
+ * Copyright (c) 2025-2026 Yao Zi <me@ziyao.cc>
+ */
+
+#include <linux/bits.h>
+#include <linux/dev_printk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+#include <linux/stmmac.h>
+
+#include "dwmac4.h"
+#include "stmmac.h"
+#include "stmmac_libpci.h"
+
+#define DRIVER_NAME "dwmac-motorcomm"
+
+#define PCI_VENDOR_ID_MOTORCOMM			0x1f0a
+
+/* Register definition */
+#define EPHY_CTRL				0x1004
+/* Clearing this bit asserts resets for internal MDIO bus and PHY */
+#define  EPHY_MDIO_PHY_RESET			BIT(0)
+#define OOB_WOL_CTRL				0x1010
+#define  OOB_WOL_CTRL_DIS			BIT(0)
+#define MGMT_INT_CTRL0				0x1100
+#define INT_MODERATION				0x1108
+#define  INT_MODERATION_RX			GENMASK(11, 0)
+#define  INT_MODERATION_TX			GENMASK(27, 16)
+#define EFUSE_OP_CTRL_0				0x1500
+#define  EFUSE_OP_MODE				GENMASK(1, 0)
+#define   EFUSE_OP_ROW_READ			0x1
+#define  EFUSE_OP_START				BIT(2)
+#define  EFUSE_OP_ADDR				GENMASK(15, 8)
+#define EFUSE_OP_CTRL_1				0x1504
+#define  EFUSE_OP_DONE				BIT(1)
+#define  EFUSE_OP_RD_DATA			GENMASK(31, 24)
+#define SYS_RESET				0x152c
+#define  SYS_RESET_RESET			BIT(31)
+#define GMAC_OFFSET				0x2000
+
+/* Constants */
+#define EFUSE_READ_TIMEOUT_US			20000
+#define EFUSE_PATCH_REGION_OFFSET		18
+#define EFUSE_PATCH_MAX_NUM			39
+#define EFUSE_ADDR_MACA0LR			0x1520
+#define EFUSE_ADDR_MACA0HR			0x1524
+
+struct motorcomm_efuse_patch {
+	__le16 addr;
+	__le32 data;
+} __packed;
+
+struct dwmac_motorcomm_priv {
+	void __iomem *base;
+};
+
+static int motorcomm_efuse_read_byte(struct dwmac_motorcomm_priv *priv,
+				     u8 offset, u8 *byte)
+{
+	u32 reg;
+	int ret;
+
+	writel(FIELD_PREP(EFUSE_OP_MODE, EFUSE_OP_ROW_READ)	|
+	       FIELD_PREP(EFUSE_OP_ADDR, offset)		|
+	       EFUSE_OP_START, priv->base + EFUSE_OP_CTRL_0);
+
+	ret = readl_poll_timeout(priv->base + EFUSE_OP_CTRL_1,
+				 reg, reg & EFUSE_OP_DONE, 2000,
+				 EFUSE_READ_TIMEOUT_US);
+
+	*byte = FIELD_GET(EFUSE_OP_RD_DATA, reg);
+
+	return ret;
+}
+
+static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv *priv,
+				      u8 index,
+				      struct motorcomm_efuse_patch *patch)
+{
+	u8 *p = (u8 *)patch, offset;
+	int i, ret;
+
+	for (i = 0; i < sizeof(*patch); i++) {
+		offset = EFUSE_PATCH_REGION_OFFSET + sizeof(*patch) * index + i;
+
+		ret = motorcomm_efuse_read_byte(priv, offset, &p[i]);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int motorcomm_efuse_get_patch_value(struct dwmac_motorcomm_priv *priv,
+					   u16 addr, u32 *value)
+{
+	struct motorcomm_efuse_patch patch;
+	int i, ret;
+
+	for (i = 0; i < EFUSE_PATCH_MAX_NUM; i++) {
+		ret = motorcomm_efuse_read_patch(priv, i, &patch);
+		if (ret)
+			return ret;
+
+		if (patch.addr == 0) {
+			return -ENOENT;
+		} else if (le16_to_cpu(patch.addr) == addr) {
+			*value = le32_to_cpu(patch.data);
+			return 0;
+		}
+	}
+
+	return -ENOENT;
+}
+
+static int motorcomm_efuse_read_mac(struct device *dev,
+				    struct dwmac_motorcomm_priv *priv, u8 *mac)
+{
+	u32 maca0lr, maca0hr;
+	int ret;
+
+	ret = motorcomm_efuse_get_patch_value(priv, EFUSE_ADDR_MACA0LR,
+					      &maca0lr);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to read maca0lr from eFuse\n");
+
+	ret = motorcomm_efuse_get_patch_value(priv, EFUSE_ADDR_MACA0HR,
+					      &maca0hr);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to read maca0hr from eFuse\n");
+
+	mac[0] = FIELD_GET(GENMASK(15, 8), maca0hr);
+	mac[1] = FIELD_GET(GENMASK(7, 0), maca0hr);
+	mac[2] = FIELD_GET(GENMASK(31, 24), maca0lr);
+	mac[3] = FIELD_GET(GENMASK(23, 16), maca0lr);
+	mac[4] = FIELD_GET(GENMASK(15, 8), maca0lr);
+	mac[5] = FIELD_GET(GENMASK(7, 0), maca0lr);
+
+	return 0;
+}
+
+static void motorcomm_deassert_mdio_phy_reset(struct dwmac_motorcomm_priv *priv)
+{
+	u32 reg = readl(priv->base + EPHY_CTRL);
+
+	reg |= EPHY_MDIO_PHY_RESET;
+
+	writel(reg, priv->base + EPHY_CTRL);
+}
+
+static void motorcomm_reset(struct dwmac_motorcomm_priv *priv)
+{
+	u32 reg = readl(priv->base + SYS_RESET);
+
+	reg &= ~SYS_RESET_RESET;
+	writel(reg, priv->base + SYS_RESET);
+
+	reg |= SYS_RESET_RESET;
+	writel(reg, priv->base + SYS_RESET);
+
+	motorcomm_deassert_mdio_phy_reset(priv);
+}
+
+static void motorcomm_init(struct dwmac_motorcomm_priv *priv)
+{
+	writel(0x0, priv->base + MGMT_INT_CTRL0);
+
+	writel(FIELD_PREP(INT_MODERATION_RX, 200) |
+	       FIELD_PREP(INT_MODERATION_TX, 200),
+	       priv->base + INT_MODERATION);
+
+	/*
+	 * OOB WOL must be disabled during normal operation, or DMA interrupts
+	 * cannot be delivered to the host.
+	 */
+	writel(OOB_WOL_CTRL_DIS, priv->base + OOB_WOL_CTRL);
+}
+
+static int motorcomm_resume(struct device *dev, void *bsp_priv)
+{
+	struct dwmac_motorcomm_priv *priv = bsp_priv;
+	int ret;
+
+	ret = stmmac_pci_plat_resume(dev, bsp_priv);
+	if (ret)
+		return ret;
+
+	/*
+	 * When recovering from D3hot, EPHY_MDIO_PHY_RESET is automatically
+	 * asserted, and must be deasserted for normal operation.
+	 */
+	motorcomm_deassert_mdio_phy_reset(priv);
+	motorcomm_init(priv);
+
+	return 0;
+}
+
+static struct plat_stmmacenet_data *
+motorcomm_default_plat_data(struct pci_dev *pdev)
+{
+	struct plat_stmmacenet_data *plat;
+	struct device *dev = &pdev->dev;
+
+	plat = stmmac_plat_dat_alloc(dev);
+	if (!plat)
+		return NULL;
+
+	plat->mdio_bus_data = devm_kzalloc(dev, sizeof(*plat->mdio_bus_data),
+					   GFP_KERNEL);
+	if (!plat->mdio_bus_data)
+		return NULL;
+
+	plat->dma_cfg = devm_kzalloc(dev, sizeof(*plat->dma_cfg), GFP_KERNEL);
+	if (!plat->dma_cfg)
+		return NULL;
+
+	plat->axi = devm_kzalloc(dev, sizeof(*plat->axi), GFP_KERNEL);
+	if (!plat->axi)
+		return NULL;
+
+	plat->dma_cfg->pbl		= DEFAULT_DMA_PBL;
+	plat->dma_cfg->pblx8		= true;
+	plat->dma_cfg->txpbl		= 32;
+	plat->dma_cfg->rxpbl		= 32;
+	plat->dma_cfg->eame		= true;
+	plat->dma_cfg->mixed_burst	= true;
+
+	plat->axi->axi_wr_osr_lmt	= 1;
+	plat->axi->axi_rd_osr_lmt	= 1;
+	plat->axi->axi_mb		= true;
+	plat->axi->axi_blen_regval	= DMA_AXI_BLEN4 | DMA_AXI_BLEN8 |
+					  DMA_AXI_BLEN16 | DMA_AXI_BLEN32;
+
+	plat->bus_id		= pci_dev_id(pdev);
+	plat->phy_interface	= PHY_INTERFACE_MODE_GMII;
+	/*
+	 * YT6801 requires an 25MHz clock input/oscillator to function, which
+	 * is likely the source of CSR clock.
+	 */
+	plat->clk_csr		= STMMAC_CSR_20_35M;
+	plat->tx_coe		= 1;
+	plat->rx_coe		= 1;
+	plat->clk_ref_rate	= 125000000;
+	plat->core_type		= DWMAC_CORE_GMAC4;
+	plat->suspend		= stmmac_pci_plat_suspend;
+	plat->resume		= motorcomm_resume;
+	plat->flags		= STMMAC_FLAG_TSO_EN |
+				  STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
+
+	return plat;
+}
+
+static void motorcomm_free_irq(void *data)
+{
+	struct pci_dev *pdev = data;
+
+	pci_free_irq_vectors(pdev);
+}
+
+static int motorcomm_setup_irq(struct pci_dev *pdev,
+			       struct stmmac_resources *res,
+			       struct plat_stmmacenet_data *plat)
+{
+	int ret;
+
+	ret = pci_alloc_irq_vectors(pdev, 6, 6, PCI_IRQ_MSIX);
+	if (ret > 0) {
+		res->rx_irq[0]	= pci_irq_vector(pdev, 0);
+		res->tx_irq[0]	= pci_irq_vector(pdev, 4);
+		res->irq	= pci_irq_vector(pdev, 5);
+
+		plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
+	} else {
+		dev_info(&pdev->dev, "failed to allocate MSI-X vector: %d\n",
+			 ret);
+		dev_info(&pdev->dev, "try MSI instead\n");
+
+		ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
+		if (ret < 0)
+			return dev_err_probe(&pdev->dev, ret,
+					     "failed to allocate MSI\n");
+
+		res->irq = pci_irq_vector(pdev, 0);
+	}
+
+	return devm_add_action_or_reset(&pdev->dev, motorcomm_free_irq, pdev);
+}
+
+static int motorcomm_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+	struct plat_stmmacenet_data *plat;
+	struct dwmac_motorcomm_priv *priv;
+	struct stmmac_resources res = {};
+	int ret;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	plat = motorcomm_default_plat_data(pdev);
+	if (!plat)
+		return -ENOMEM;
+
+	plat->bsp_priv = priv;
+
+	ret = pcim_enable_device(pdev);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "failed to enable device\n");
+
+	priv->base = pcim_iomap_region(pdev, 0, DRIVER_NAME);
+	if (IS_ERR(priv->base))
+		return dev_err_probe(&pdev->dev, PTR_ERR(priv->base),
+				     "failed to map IO region\n");
+
+	pci_set_master(pdev);
+
+	/*
+	 * Some PCIe addons cards based on YT6801 don't deliver MSI(X) with ASPM
+	 * enabled. Sadly there isn't a reliable way to read out OEM of the
+	 * card, so let's disable L1 state unconditionally for safety.
+	 */
+	ret = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1);
+	if (ret)
+		dev_warn(&pdev->dev, "failed to disable L1 state: %d\n", ret);
+
+	motorcomm_reset(priv);
+
+	ret = motorcomm_efuse_read_mac(&pdev->dev, priv, res.mac);
+	if (ret == -ENOENT) {
+		dev_warn(&pdev->dev, "eFuse contains no valid MAC address\n");
+		dev_warn(&pdev->dev, "fallback to random MAC address\n");
+
+		eth_random_addr(res.mac);
+	} else if (ret) {
+		return dev_err_probe(&pdev->dev, ret,
+				     "failed to read MAC address from eFuse\n");
+	}
+
+	ret = motorcomm_setup_irq(pdev, &res, plat);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "failed to setup IRQ\n");
+
+	motorcomm_init(priv);
+
+	res.addr = priv->base + GMAC_OFFSET;
+
+	return stmmac_dvr_probe(&pdev->dev, plat, &res);
+}
+
+static void motorcomm_remove(struct pci_dev *pdev)
+{
+	stmmac_dvr_remove(&pdev->dev);
+}
+
+static const struct pci_device_id dwmac_motorcomm_pci_id_table[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_MOTORCOMM, 0x6801) },
+	{ },
+};
+MODULE_DEVICE_TABLE(pci, dwmac_motorcomm_pci_id_table);
+
+static struct pci_driver dwmac_motorcomm_pci_driver = {
+	.name = DRIVER_NAME,
+	.id_table = dwmac_motorcomm_pci_id_table,
+	.probe = motorcomm_probe,
+	.remove = motorcomm_remove,
+	.driver = {
+		.pm = &stmmac_simple_pm_ops,
+	},
+};
+
+module_pci_driver(dwmac_motorcomm_pci_driver);
+
+MODULE_DESCRIPTION("DWMAC glue driver for Motorcomm PCI Ethernet controllers");
+MODULE_AUTHOR("Yao Zi <me@ziyao.cc>");
+MODULE_LICENSE("GPL");
-- 
2.52.0

RE: [PATCH RESEND net-next v6 2/3] net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller

[Sai Krishna Gajula]

> -----Original Message-----
> From: Yao Zi <me@ziyao.cc>
> Sent: Friday, January 9, 2026 3:05 PM
> To: Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Frank
> <Frank.Sae@motor-comm.com>; Heiner Kallweit <hkallweit1@gmail.com>;
> Russell King <linux@armlinux.org.uk>; Russell King (Oracle)
> <rmk+kernel@armlinux.org.uk>; Vladimir Oltean
> <vladimir.oltean@nxp.com>; Chen-Yu Tsai <wens@csie.org>; Jisheng Zhang
> <jszhang@kernel.org>; Furong Xu <0x1207@gmail.com>
> Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; Mingcong Bai
> <jeffbai@aosc.io>; Kexy Biscuit <kexybiscuit@aosc.io>; Yao Zi <me@ziyao.cc>;
> Runhua He <hua@aosc.io>; Xi Ruoyao <xry111@xry111.site>
> Subject: [PATCH RESEND net-next v6 2/3] net: stmmac: Add glue
> driver for Motorcomm YT6801 ethernet controller
> 
> Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
> integrates an GbE phy, supporting WOL, VLAN tagging and various types of
> offloading. It ships an on-chip eFuse for storing various vendor configuration,
> including MAC address.
> Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
> integrates an GbE phy, supporting WOL, VLAN tagging and various types of
> offloading. It ships an on-chip eFuse for storing various vendor configuration,
> including MAC address.
> 
> This patch adds basic glue code for the controller, allowing it to be set up and
> transmit data at a reasonable speed. Features like WOL could be implemented
> in the future.
> 
> Signed-off-by: Yao Zi <me@ziyao.cc>
> Tested-by: Mingcong Bai <jeffbai@aosc.io>
> Tested-by: Runhua He <hua@aosc.io>
> Tested-by: Xi Ruoyao <xry111@xry111.site>
> ---
>  drivers/net/ethernet/stmicro/stmmac/Kconfig   |   9 +
>  drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
>  .../ethernet/stmicro/stmmac/dwmac-motorcomm.c | 384
> ++++++++++++++++++
>  3 files changed, 394 insertions(+)
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-
> motorcomm.c
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index 907fe2e927f0..07088d03dbab 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -374,6 +374,15 @@ config DWMAC_LOONGSON
>  	  This selects the LOONGSON PCI bus support for the stmmac driver,
>  	  Support for ethernet controller on Loongson-2K1000 SoC and
> LS7A1000 bridge.
> 
> +config DWMAC_MOTORCOMM
> +	tristate "Motorcomm PCI DWMAC support"
> +	depends on PCI
> +	select MOTORCOMM_PHY
> +	select STMMAC_LIBPCI
> +	help
> +	  This enables glue driver for Motorcomm DWMAC-based PCI
> Ethernet
> +	  controllers. Currently only YT6801 is supported.
> +
>  config STMMAC_PCI
>  	tristate "STMMAC PCI bus support"
>  	depends on PCI
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
> b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index 7bf528731034..c9263987ef8d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -48,4 +48,5 @@ obj-$(CONFIG_STMMAC_LIBPCI)	+= stmmac_libpci.o
>  obj-$(CONFIG_STMMAC_PCI)	+= stmmac-pci.o
>  obj-$(CONFIG_DWMAC_INTEL)	+= dwmac-intel.o
>  obj-$(CONFIG_DWMAC_LOONGSON)	+= dwmac-loongson.o
> +obj-$(CONFIG_DWMAC_MOTORCOMM)	+= dwmac-motorcomm.o
>  stmmac-pci-objs:= stmmac_pci.o
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> new file mode 100644
> index 000000000000..8b45b9cf7202
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> @@ -0,0 +1,384 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * DWMAC glue driver for Motorcomm PCI Ethernet controllers
> + *
> + * Copyright (c) 2025-2026 Yao Zi <me@ziyao.cc>  */
> +
> +#include <linux/bits.h>
> +#include <linux/dev_printk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/slab.h>
> +#include <linux/stmmac.h>
> +
> +#include "dwmac4.h"
> +#include "stmmac.h"
> +#include "stmmac_libpci.h"
> +
> +#define DRIVER_NAME "dwmac-motorcomm"
> +
> +#define PCI_VENDOR_ID_MOTORCOMM			0x1f0a
> +
> +/* Register definition */
> +#define EPHY_CTRL				0x1004
> +/* Clearing this bit asserts resets for internal MDIO bus and PHY */
> +#define  EPHY_MDIO_PHY_RESET			BIT(0)
> +#define OOB_WOL_CTRL				0x1010
> +#define  OOB_WOL_CTRL_DIS			BIT(0)
> +#define MGMT_INT_CTRL0				0x1100
> +#define INT_MODERATION				0x1108
> +#define  INT_MODERATION_RX			GENMASK(11, 0)
> +#define  INT_MODERATION_TX			GENMASK(27, 16)
> +#define EFUSE_OP_CTRL_0				0x1500
> +#define  EFUSE_OP_MODE				GENMASK(1, 0)
> +#define   EFUSE_OP_ROW_READ			0x1
> +#define  EFUSE_OP_START				BIT(2)
> +#define  EFUSE_OP_ADDR				GENMASK(15, 8)
> +#define EFUSE_OP_CTRL_1				0x1504
> +#define  EFUSE_OP_DONE				BIT(1)
> +#define  EFUSE_OP_RD_DATA			GENMASK(31, 24)
> +#define SYS_RESET				0x152c
> +#define  SYS_RESET_RESET			BIT(31)
> +#define GMAC_OFFSET				0x2000
> +
> +/* Constants */
> +#define EFUSE_READ_TIMEOUT_US			20000
> +#define EFUSE_PATCH_REGION_OFFSET		18
> +#define EFUSE_PATCH_MAX_NUM			39
> +#define EFUSE_ADDR_MACA0LR			0x1520
> +#define EFUSE_ADDR_MACA0HR			0x1524
> +
> +struct motorcomm_efuse_patch {
> +	__le16 addr;
> +	__le32 data;
> +} __packed;
> +
> +struct dwmac_motorcomm_priv {
> +	void __iomem *base;
> +};
> +
> +static int motorcomm_efuse_read_byte(struct dwmac_motorcomm_priv
> *priv,
> +				     u8 offset, u8 *byte)
> +{
> +	u32 reg;
> +	int ret;
> +
> +	writel(FIELD_PREP(EFUSE_OP_MODE, EFUSE_OP_ROW_READ)	|
> +	       FIELD_PREP(EFUSE_OP_ADDR, offset)		|
> +	       EFUSE_OP_START, priv->base + EFUSE_OP_CTRL_0);
> +
> +	ret = readl_poll_timeout(priv->base + EFUSE_OP_CTRL_1,
> +				 reg, reg & EFUSE_OP_DONE, 2000,
> +				 EFUSE_READ_TIMEOUT_US);
> +
> +	*byte = FIELD_GET(EFUSE_OP_RD_DATA, reg);
> +
> +	return ret;
> +}
> +
> +static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
> *priv,
> +				      u8 index,
> +				      struct motorcomm_efuse_patch *patch) {
Minor nit
This format breaks  kernel style function definition, use as below ( "{" in next line)
static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
                                                                          *priv,
				                 u8 index,
				                 struct motorcomm_efuse_patch *patch) 
{

> +	u8 *p = (u8 *)patch, offset;
> +	int i, ret;
> +
> +	for (i = 0; i < sizeof(*patch); i++) {
> +		offset = EFUSE_PATCH_REGION_OFFSET + sizeof(*patch) *
> index + i;
> +
> +		ret = motorcomm_efuse_read_byte(priv, offset, &p[i]);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int motorcomm_efuse_get_patch_value(struct
> dwmac_motorcomm_priv *priv,
> +					   u16 addr, u32 *value)
> +{
> +	struct motorcomm_efuse_patch patch;
> +	int i, ret;
> +
> +	for (i = 0; i < EFUSE_PATCH_MAX_NUM; i++) {
> +		ret = motorcomm_efuse_read_patch(priv, i, &patch);
> +		if (ret)
> +			return ret;
> +
> +		if (patch.addr == 0) {
> +			return -ENOENT;
> +		} else if (le16_to_cpu(patch.addr) == addr) {
> +			*value = le32_to_cpu(patch.data);
> +			return 0;
> +		}
> +	}
> +
> +	return -ENOENT;
> +}
> +
> +static int motorcomm_efuse_read_mac(struct device *dev,
> +				    struct dwmac_motorcomm_priv *priv, u8
> *mac) {

This format breaks  kernel style function definition, use as below ( "{" in next line), same in other places.

> +	u32 maca0lr, maca0hr;
> +	int ret;
> +
> +	ret = motorcomm_efuse_get_patch_value(priv,
> EFUSE_ADDR_MACA0LR,
> +					      &maca0lr);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to read maca0lr from eFuse\n");
> +
> +	ret = motorcomm_efuse_get_patch_value(priv,
> EFUSE_ADDR_MACA0HR,
> +					      &maca0hr);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to read maca0hr from eFuse\n");
> +
> +	mac[0] = FIELD_GET(GENMASK(15, 8), maca0hr);
> +	mac[1] = FIELD_GET(GENMASK(7, 0), maca0hr);
> +	mac[2] = FIELD_GET(GENMASK(31, 24), maca0lr);
> +	mac[3] = FIELD_GET(GENMASK(23, 16), maca0lr);
> +	mac[4] = FIELD_GET(GENMASK(15, 8), maca0lr);
> +	mac[5] = FIELD_GET(GENMASK(7, 0), maca0lr);
> +
> +	return 0;
> +}
> +
> +static void motorcomm_deassert_mdio_phy_reset(struct
> +dwmac_motorcomm_priv *priv) {
> +	u32 reg = readl(priv->base + EPHY_CTRL);
> +
> +	reg |= EPHY_MDIO_PHY_RESET;
> +
> +	writel(reg, priv->base + EPHY_CTRL);
> +}
> +
> +static void motorcomm_reset(struct dwmac_motorcomm_priv *priv) {
> +	u32 reg = readl(priv->base + SYS_RESET);
> +
> +	reg &= ~SYS_RESET_RESET;
> +	writel(reg, priv->base + SYS_RESET);
> +
> +	reg |= SYS_RESET_RESET;
> +	writel(reg, priv->base + SYS_RESET);
> +
> +	motorcomm_deassert_mdio_phy_reset(priv);
> +}
> +
> +static void motorcomm_init(struct dwmac_motorcomm_priv *priv) {
> +	writel(0x0, priv->base + MGMT_INT_CTRL0);
> +
> +	writel(FIELD_PREP(INT_MODERATION_RX, 200) |
> +	       FIELD_PREP(INT_MODERATION_TX, 200),
> +	       priv->base + INT_MODERATION);
> +
> +	/*
> +	 * OOB WOL must be disabled during normal operation, or DMA
> interrupts
> +	 * cannot be delivered to the host.
> +	 */
> +	writel(OOB_WOL_CTRL_DIS, priv->base + OOB_WOL_CTRL); }
> +
> +static int motorcomm_resume(struct device *dev, void *bsp_priv) {
> +	struct dwmac_motorcomm_priv *priv = bsp_priv;
> +	int ret;
> +
> +	ret = stmmac_pci_plat_resume(dev, bsp_priv);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * When recovering from D3hot, EPHY_MDIO_PHY_RESET is
> automatically
> +	 * asserted, and must be deasserted for normal operation.
> +	 */
> +	motorcomm_deassert_mdio_phy_reset(priv);
> +	motorcomm_init(priv);
> +
> +	return 0;
> +}
> +
> +static struct plat_stmmacenet_data *
> +motorcomm_default_plat_data(struct pci_dev *pdev) {
> +	struct plat_stmmacenet_data *plat;
> +	struct device *dev = &pdev->dev;
> +
> +	plat = stmmac_plat_dat_alloc(dev);
> +	if (!plat)
> +		return NULL;
> +
> +	plat->mdio_bus_data = devm_kzalloc(dev, sizeof(*plat-
> >mdio_bus_data),
> +					   GFP_KERNEL);
> +	if (!plat->mdio_bus_data)
> +		return NULL;
> +
> +	plat->dma_cfg = devm_kzalloc(dev, sizeof(*plat->dma_cfg),
> GFP_KERNEL);
> +	if (!plat->dma_cfg)
> +		return NULL;
> +
> +	plat->axi = devm_kzalloc(dev, sizeof(*plat->axi), GFP_KERNEL);
> +	if (!plat->axi)
> +		return NULL;
> +
> +	plat->dma_cfg->pbl		= DEFAULT_DMA_PBL;
> +	plat->dma_cfg->pblx8		= true;
> +	plat->dma_cfg->txpbl		= 32;
> +	plat->dma_cfg->rxpbl		= 32;
> +	plat->dma_cfg->eame		= true;
> +	plat->dma_cfg->mixed_burst	= true;
> +
> +	plat->axi->axi_wr_osr_lmt	= 1;
> +	plat->axi->axi_rd_osr_lmt	= 1;
> +	plat->axi->axi_mb		= true;
> +	plat->axi->axi_blen_regval	= DMA_AXI_BLEN4 |
> DMA_AXI_BLEN8 |
> +					  DMA_AXI_BLEN16 |
> DMA_AXI_BLEN32;
> +
> +	plat->bus_id		= pci_dev_id(pdev);
> +	plat->phy_interface	= PHY_INTERFACE_MODE_GMII;
> +	/*
> +	 * YT6801 requires an 25MHz clock input/oscillator to function, which
> +	 * is likely the source of CSR clock.
> +	 */
> +	plat->clk_csr		= STMMAC_CSR_20_35M;
> +	plat->tx_coe		= 1;
> +	plat->rx_coe		= 1;
> +	plat->clk_ref_rate	= 125000000;
> +	plat->core_type		= DWMAC_CORE_GMAC4;
> +	plat->suspend		= stmmac_pci_plat_suspend;
> +	plat->resume		= motorcomm_resume;
> +	plat->flags		= STMMAC_FLAG_TSO_EN |
> +				  STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
> +
> +	return plat;
> +}
> +
> +static void motorcomm_free_irq(void *data) {
> +	struct pci_dev *pdev = data;
> +
> +	pci_free_irq_vectors(pdev);
> +}
> +
> +static int motorcomm_setup_irq(struct pci_dev *pdev,
> +			       struct stmmac_resources *res,
> +			       struct plat_stmmacenet_data *plat) {
> +	int ret;
> +
> +	ret = pci_alloc_irq_vectors(pdev, 6, 6, PCI_IRQ_MSIX);
> +	if (ret > 0) {
> +		res->rx_irq[0]	= pci_irq_vector(pdev, 0);
> +		res->tx_irq[0]	= pci_irq_vector(pdev, 4);
> +		res->irq	= pci_irq_vector(pdev, 5);
> +
> +		plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> +	} else {
> +		dev_info(&pdev->dev, "failed to allocate MSI-X vector: %d\n",
> +			 ret);
> +		dev_info(&pdev->dev, "try MSI instead\n");
> +
> +		ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
> +		if (ret < 0)
> +			return dev_err_probe(&pdev->dev, ret,
> +					     "failed to allocate MSI\n");
> +
> +		res->irq = pci_irq_vector(pdev, 0);
> +	}

If possible, add enum for MAX MSIX count (in this case 6 ), or dynamic values as per hardware. 
> +
> +	return devm_add_action_or_reset(&pdev->dev,
> motorcomm_free_irq, pdev);
> +}
> +
> +static int motorcomm_probe(struct pci_dev *pdev, const struct
> +pci_device_id *id) {
> +	struct plat_stmmacenet_data *plat;
> +	struct dwmac_motorcomm_priv *priv;
> +	struct stmmac_resources res = {};
> +	int ret;
> +
> +	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	plat = motorcomm_default_plat_data(pdev);
> +	if (!plat)
> +		return -ENOMEM;
> +
> +	plat->bsp_priv = priv;
> +
> +	ret = pcim_enable_device(pdev);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "failed to enable device\n");
> +
> +	priv->base = pcim_iomap_region(pdev, 0, DRIVER_NAME);
> +	if (IS_ERR(priv->base))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(priv->base),
> +				     "failed to map IO region\n");
> +
> +	pci_set_master(pdev);
> +
> +	/*
> +	 * Some PCIe addons cards based on YT6801 don't deliver MSI(X) with
> ASPM
> +	 * enabled. Sadly there isn't a reliable way to read out OEM of the
> +	 * card, so let's disable L1 state unconditionally for safety.
> +	 */
> +	ret = pci_disable_link_state(pdev, PCIE_LINK_STATE_L1);
> +	if (ret)
> +		dev_warn(&pdev->dev, "failed to disable L1 state: %d\n", ret);
> +
> +	motorcomm_reset(priv);
> +
> +	ret = motorcomm_efuse_read_mac(&pdev->dev, priv, res.mac);
> +	if (ret == -ENOENT) {
> +		dev_warn(&pdev->dev, "eFuse contains no valid MAC
> address\n");
> +		dev_warn(&pdev->dev, "fallback to random MAC
> address\n");
> +
> +		eth_random_addr(res.mac);
> +	} else if (ret) {
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "failed to read MAC address from
> eFuse\n");
> +	}
> +
> +	ret = motorcomm_setup_irq(pdev, &res, plat);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "failed to setup
> IRQ\n");
> +
> +	motorcomm_init(priv);
> +
> +	res.addr = priv->base + GMAC_OFFSET;
> +
> +	return stmmac_dvr_probe(&pdev->dev, plat, &res); }
> +
> +static void motorcomm_remove(struct pci_dev *pdev) {
> +	stmmac_dvr_remove(&pdev->dev);
> +}
> +
> +static const struct pci_device_id dwmac_motorcomm_pci_id_table[] = {
> +	{ PCI_DEVICE(PCI_VENDOR_ID_MOTORCOMM, 0x6801) },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(pci, dwmac_motorcomm_pci_id_table);
> +
> +static struct pci_driver dwmac_motorcomm_pci_driver = {
> +	.name = DRIVER_NAME,
> +	.id_table = dwmac_motorcomm_pci_id_table,
> +	.probe = motorcomm_probe,
> +	.remove = motorcomm_remove,
> +	.driver = {
> +		.pm = &stmmac_simple_pm_ops,
> +	},
> +};
> +
> +module_pci_driver(dwmac_motorcomm_pci_driver);
> +
> +MODULE_DESCRIPTION("DWMAC glue driver for Motorcomm PCI Ethernet
> +controllers"); MODULE_AUTHOR("Yao Zi <me@ziyao.cc>");
> +MODULE_LICENSE("GPL");
> --
> 2.52.0
> 
Reviewed-by: Sai Krishna <saikrishnag@marvell.com>

Re: [PATCH RESEND net-next v6 2/3] net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller

[Yao Zi]

On Mon, Jan 12, 2026 at 06:10:26AM +0000, Sai Krishna Gajula wrote:
> 
> 
> > -----Original Message-----
> > From: Yao Zi <me@ziyao.cc>
> > Sent: Friday, January 9, 2026 3:05 PM
> > To: Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller
> > <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> > Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Frank
> > <Frank.Sae@motor-comm.com>; Heiner Kallweit <hkallweit1@gmail.com>;
> > Russell King <linux@armlinux.org.uk>; Russell King (Oracle)
> > <rmk+kernel@armlinux.org.uk>; Vladimir Oltean
> > <vladimir.oltean@nxp.com>; Chen-Yu Tsai <wens@csie.org>; Jisheng Zhang
> > <jszhang@kernel.org>; Furong Xu <0x1207@gmail.com>
> > Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; Mingcong Bai
> > <jeffbai@aosc.io>; Kexy Biscuit <kexybiscuit@aosc.io>; Yao Zi <me@ziyao.cc>;
> > Runhua He <hua@aosc.io>; Xi Ruoyao <xry111@xry111.site>
> > Subject: [PATCH RESEND net-next v6 2/3] net: stmmac: Add glue
> > driver for Motorcomm YT6801 ethernet controller
> > 
> > Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
> > integrates an GbE phy, supporting WOL, VLAN tagging and various types of
> > offloading. It ships an on-chip eFuse for storing various vendor configuration,
> > including MAC address.
> > Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
> > integrates an GbE phy, supporting WOL, VLAN tagging and various types of
> > offloading. It ships an on-chip eFuse for storing various vendor configuration,
> > including MAC address.
> > 
> > This patch adds basic glue code for the controller, allowing it to be set up and
> > transmit data at a reasonable speed. Features like WOL could be implemented
> > in the future.
> > 
> > Signed-off-by: Yao Zi <me@ziyao.cc>
> > Tested-by: Mingcong Bai <jeffbai@aosc.io>
> > Tested-by: Runhua He <hua@aosc.io>
> > Tested-by: Xi Ruoyao <xry111@xry111.site>
> > ---
> >  drivers/net/ethernet/stmicro/stmmac/Kconfig   |   9 +
> >  drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
> >  .../ethernet/stmicro/stmmac/dwmac-motorcomm.c | 384
> > ++++++++++++++++++
> >  3 files changed, 394 insertions(+)

...

> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> > b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
> > new file mode 100644
> > index 000000000000..8b45b9cf7202
> > --- /dev/null
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c

...

> > +static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
> > *priv,
> > +				      u8 index,
> > +				      struct motorcomm_efuse_patch *patch) {
> Minor nit
> This format breaks  kernel style function definition, use as below ( "{" in next line)
> static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
>                                                                           *priv,
> 				                 u8 index,
> 				                 struct motorcomm_efuse_patch *patch) 
> {

This is strange, I didn't put the left curly brace in the same line as
the argument list. You could confirm this in the mbox archived by
lore[1]. Same for other functions.

I've talked to other recipients of the patch, and one uses Outlook as
MTA reported similar issues. It seems Outlook MTA (not the server)
automatically removes the line break and the plus sign before the curly
brace.

I checked your Message-ID and found you're also using Outlook as service
provider, if Outlook is also your MTA, could you try turn off option
"Remove extra line breaks in plain text messages" and see whether the
problem gets fixed?

...

> > +static int motorcomm_setup_irq(struct pci_dev *pdev,
> > +			       struct stmmac_resources *res,
> > +			       struct plat_stmmacenet_data *plat) {
> > +	int ret;
> > +
> > +	ret = pci_alloc_irq_vectors(pdev, 6, 6, PCI_IRQ_MSIX);
> > +	if (ret > 0) {
> > +		res->rx_irq[0]	= pci_irq_vector(pdev, 0);
> > +		res->tx_irq[0]	= pci_irq_vector(pdev, 4);
> > +		res->irq	= pci_irq_vector(pdev, 5);
> > +
> > +		plat->flags |= STMMAC_FLAG_MULTI_MSI_EN;
> > +	} else {
> > +		dev_info(&pdev->dev, "failed to allocate MSI-X vector: %d\n",
> > +			 ret);
> > +		dev_info(&pdev->dev, "try MSI instead\n");
> > +
> > +		ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
> > +		if (ret < 0)
> > +			return dev_err_probe(&pdev->dev, ret,
> > +					     "failed to allocate MSI\n");
> > +
> > +		res->irq = pci_irq_vector(pdev, 0);
> > +	}
> 
> If possible, add enum for MAX MSIX count (in this case 6 ), or dynamic values as per hardware. 

The only Motorcomm PCIe ethernet controller I could find is YT6801, so
I don't think there's a need for per-hardware values (at least for now).
Will add a constant to represent MSI-X count in the next version.

...

> Reviewed-by: Sai Krishna <saikrishnag@marvell.com>

Thanks for reviewing.

Best regards,
Yao Zi

[1]: https://lore.kernel.org/all/20260109093445.46791-4-me@ziyao.cc/raw

Re: [PATCH RESEND net-next v6 2/3] net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller

[Russell King (Oracle)]

On Mon, Jan 12, 2026 at 06:10:26AM +0000, Sai Krishna Gajula wrote:
> > +static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
> > *priv,
> > +				      u8 index,
> > +				      struct motorcomm_efuse_patch *patch) {
> Minor nit
> This format breaks  kernel style function definition, use as below ( "{" in next line)
> static int motorcomm_efuse_read_patch(struct dwmac_motorcomm_priv
>                                                                           *priv,
> 				                 u8 index,
> 				                 struct motorcomm_efuse_patch *patch) 
> {

Your email client is lying to you. I received the patch with the curley
brace on the start of next line.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

[PATCH RESEND net-next v6 3/3] MAINTAINERS: Assign myself as maintainer of Motorcomm DWMAC glue driver

[Yao Zi]

I volunteer to maintain the DWMAC glue driver for Motorcomm ethernet
controllers.

Signed-off-by: Yao Zi <me@ziyao.cc>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e083f15fc28..4ae3736d8010 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17711,6 +17711,12 @@ F:	drivers/most/
 F:	drivers/staging/most/
 F:	include/linux/most.h
 
+MOTORCOMM DWMAC GLUE DRIVER
+M:	Yao Zi <me@ziyao.cc>
+L:	netdev@vger.kernel.org
+S:	Maintained
+F:	drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
+
 MOTORCOMM PHY DRIVER
 M:	Frank <Frank.Sae@motor-comm.com>
 L:	netdev@vger.kernel.org
-- 
2.52.0

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri,  9 Jan 2026 09:34:43 +0000 you wrote:
> This series adds glue driver for Motorcomm YT6801 PCIe ethernet
> controller, which is considered mostly compatible with DWMAC-4 IP by
> inspecting the register layout[1]. It integrates a Motorcomm YT8531S PHY
> (confirmed by reading PHY ID) and GMII is used to connect the PHY to
> MAC[2].
> 
> The initialization logic of the MAC is mostly based on previous upstream
> effort for the controller[3] and the Deepin-maintained downstream Linux
> driver[4] licensed under GPL-2.0 according to its SPDX headers. However,
> this series is a completely re-write of the previous patch series,
> utilizing the existing DWMAC4 driver and introducing a glue driver only.
> 
> [...]

Here is the summary with links:
  - [RESEND,net-next,v6,1/3] net: phy: motorcomm: Support YT8531S PHY in YT6801 Ethernet controller
    https://git.kernel.org/netdev/net-next/c/365e649361cd
  - [RESEND,net-next,v6,2/3] net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller
    https://git.kernel.org/netdev/net-next/c/02ff155ea281
  - [RESEND,net-next,v6,3/3] MAINTAINERS: Assign myself as maintainer of Motorcomm DWMAC glue driver
    https://git.kernel.org/netdev/net-next/c/40ca42c8429b

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Georg Gottleuber]

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

Hi,

I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
revealed that tx is only 100Mbit/s:

## YT6801 TX

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  8.75 MBytes  73.3 Mbits/sec    0    164 KBytes

[  5]   1.00-2.00   sec  8.62 MBytes  72.4 Mbits/sec    0    164 KBytes

[  5]   2.00-3.00   sec  8.62 MBytes  72.4 Mbits/sec    0    164 KBytes

[  5]   3.00-4.00   sec  8.12 MBytes  68.2 Mbits/sec    0    164 KBytes

[  5]   4.00-5.00   sec  8.62 MBytes  72.3 Mbits/sec    0    164 KBytes

[  5]   5.00-6.00   sec  8.50 MBytes  71.3 Mbits/sec    0    164 KBytes

[  5]   6.00-7.00   sec  8.25 MBytes  69.2 Mbits/sec    0    164 KBytes

[  5]   7.00-8.00   sec  8.62 MBytes  72.4 Mbits/sec    0    164 KBytes

[  5]   8.00-9.00   sec  8.50 MBytes  71.3 Mbits/sec    0    164 KBytes

[  5]   9.00-10.00  sec  8.62 MBytes  72.3 Mbits/sec    0    164 KBytes

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  85.2 MBytes  71.5 Mbits/sec    0             sender
[  5]   0.00-10.05  sec  84.4 MBytes  70.5 Mbits/sec
receiver


## YT6801 RX

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   112 MBytes   939 Mbits/sec
[  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec
[  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec
[  5]   3.00-4.00   sec   112 MBytes   942 Mbits/sec
[  5]   4.00-5.00   sec   112 MBytes   942 Mbits/sec
[  5]   5.00-6.00   sec   112 MBytes   943 Mbits/sec
[  5]   6.00-7.00   sec   112 MBytes   941 Mbits/sec
[  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec
[  5]   8.00-9.00   sec   112 MBytes   942 Mbits/sec
[  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  1.10 GBytes   941 Mbits/sec   88             sender
[  5]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec
receiver

With our normally used DKMS module, Ethernet works with full-duplex and
gigabit. Attached are some logs from lspci and dmesg. Do you have any
idea how I can debug this further?

Regards,
Georg


[-- Attachment #2: dmesg_lspci_motorcomm_ibp14gen9_AMD.txt --]
[-- Type: text/plain, Size: 6246 bytes --]

root@tuxedo:/home/test# uname -a
Linux tuxedo 6.19.0-rc5-next-20260116ln02 #14 SMP PREEMPT_DYNAMIC Fri Jan 16 19:02:10 CET 2026 x86_64 x86_64 x86_64 GNU/Linux
root@tuxedo:/home/test# lspci -nn
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Root Complex [1022:14e8]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Phoenix IOMMU [1022:14e9]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Dummy Host Bridge [1022:14ea]
00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Phoenix GPP Bridge [1022:14ed]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Dummy Host Bridge [1022:14ea]
00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Phoenix GPP Bridge [1022:14ee]
00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Phoenix GPP Bridge [1022:14ee]
00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Phoenix GPP Bridge [1022:14ee]
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Dummy Host Bridge [1022:14ea]
00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Dummy Host Bridge [1022:14ea]
00:04.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel [1022:14ef]
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Dummy Host Bridge [1022:14ea]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Phoenix Internal GPP Bridge to Bus [C:A] [1022:14eb]
00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Phoenix Internal GPP Bridge to Bus [C:A] [1022:14eb]
00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Phoenix Internal GPP Bridge to Bus [C:A] [1022:14eb]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 71)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 0 [1022:14f0]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 1 [1022:14f1]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 2 [1022:14f2]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 3 [1022:14f3]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 4 [1022:14f4]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 5 [1022:14f5]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 6 [1022:14f6]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Phoenix Data Fabric; Function 7 [1022:14f7]
01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller 980 (DRAM-less) [144d:a809]
02:00.0 Ethernet controller [0200]: Motorcomm Microelectronics. YT6801 Gigabit Ethernet Controller [1f0a:6801] (rev 01)
03:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak] [8086:2725] (rev 1a)
04:00.0 SD Host controller [0805]: Genesys Logic, Inc GL9767 PCIe SD UHS-II & SD Express Card Reader Controller [17a0:9767] (rev 02)
65:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] HawkPoint1 [1002:1900] (rev c5)
65:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Radeon High Definition Audio Controller [1002:1640]
65:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Phoenix CCP/PSP 3.0 Device [1022:15c7]
65:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15b9]
65:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15ba]
65:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] Audio Coprocessor [1022:15e2] (rev 63)
65:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Ryzen HD Audio Controller [1022:15e3]
66:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Phoenix Dummy Function [1022:14ec]
66:00.1 Signal processing controller [1180]: Advanced Micro Devices, Inc. [AMD] AMD IPU Device [1022:1502]
67:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Phoenix Dummy Function [1022:14ec]
67:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15c0]
67:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:15c1]
67:00.6 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Pink Sardine USB4/Thunderbolt NHI controller #2 [1022:1669]
root@tuxedo:/home/test# dmesg | grep motorcomm
[    1.122654] dwmac-motorcomm 0000:02:00.0: User ID: 0x10, Synopsys ID: 0x52
[    1.122662] dwmac-motorcomm 0000:02:00.0:    DWMAC4/5
[    1.122675] dwmac-motorcomm 0000:02:00.0: DMA HW capability register supported
[    1.122677] dwmac-motorcomm 0000:02:00.0: RX Checksum Offload Engine supported
[    1.122679] dwmac-motorcomm 0000:02:00.0: TX Checksum insertion supported
[    1.122680] dwmac-motorcomm 0000:02:00.0: Wake-Up On Lan supported
[    1.122683] dwmac-motorcomm 0000:02:00.0: TSO supported
[    1.122684] dwmac-motorcomm 0000:02:00.0: Enable RX Mitigation via HW Watchdog Timer
[    1.122687] dwmac-motorcomm 0000:02:00.0: Enabled L3L4 Flow TC (entries=2)
[    1.122689] dwmac-motorcomm 0000:02:00.0: Enabled RFS Flow TC (entries=10)
[    1.122691] dwmac-motorcomm 0000:02:00.0: TSO feature enabled
[    1.122692] dwmac-motorcomm 0000:02:00.0: SPH feature enabled
[    1.122694] dwmac-motorcomm 0000:02:00.0: Using 48/48 bits DMA host/device width
[    1.378126] dwmac-motorcomm 0000:02:00.0 enp2s0: renamed from eth0
[    5.801051] dwmac-motorcomm 0000:02:00.0 enp2s0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    5.805359] dwmac-motorcomm 0000:02:00.0 enp2s0: PHY [stmmac-200:00] driver [YT8531S Gigabit Ethernet] (irq=POLL)
[    5.815438] dwmac-motorcomm 0000:02:00.0 enp2s0: Enabling Safety Features
[    5.815623] dwmac-motorcomm 0000:02:00.0 enp2s0: PTP not supported by HW
[    5.815626] dwmac-motorcomm 0000:02:00.0 enp2s0: configuring for phy/gmii link mode
[    8.910725] dwmac-motorcomm 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control rx/tx

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Russell King (Oracle)]

On Mon, Jan 19, 2026 at 04:33:17PM +0100, Georg Gottleuber wrote:
> Hi,
> 
> I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
> revealed that tx is only 100Mbit/s:
> 
> ## YT6801 TX
> 
> [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
> [  5]   0.00-1.00   sec  8.75 MBytes  73.3 Mbits/sec    0    164 KBytes
> 
> [  5]   1.00-2.00   sec  8.62 MBytes  72.4 Mbits/sec    0    164 KBytes
> 
> [  5]   2.00-3.00   sec  8.62 MBytes  72.4 Mbits/sec    0    164 KBytes
> 
> [  5]   3.00-4.00   sec  8.12 MBytes  68.2 Mbits/sec    0    164 KBytes
> 
> [  5]   4.00-5.00   sec  8.62 MBytes  72.3 Mbits/sec    0    164 KBytes
> 
> [  5]   5.00-6.00   sec  8.50 MBytes  71.3 Mbits/sec    0    164 KBytes
> 
> [  5]   6.00-7.00   sec  8.25 MBytes  69.2 Mbits/sec    0    164 KBytes
> 
> [  5]   7.00-8.00   sec  8.62 MBytes  72.4 Mbits/sec    0    164 KBytes
> 
> [  5]   8.00-9.00   sec  8.50 MBytes  71.3 Mbits/sec    0    164 KBytes
> 
> [  5]   9.00-10.00  sec  8.62 MBytes  72.3 Mbits/sec    0    164 KBytes
> 
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-10.00  sec  85.2 MBytes  71.5 Mbits/sec    0             sender
> [  5]   0.00-10.05  sec  84.4 MBytes  70.5 Mbits/sec
> receiver
> 
> 
> ## YT6801 RX
> 
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec   112 MBytes   939 Mbits/sec
> [  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec
> [  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec
> [  5]   3.00-4.00   sec   112 MBytes   942 Mbits/sec
> [  5]   4.00-5.00   sec   112 MBytes   942 Mbits/sec
> [  5]   5.00-6.00   sec   112 MBytes   943 Mbits/sec
> [  5]   6.00-7.00   sec   112 MBytes   941 Mbits/sec
> [  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec
> [  5]   8.00-9.00   sec   112 MBytes   942 Mbits/sec
> [  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-10.04  sec  1.10 GBytes   941 Mbits/sec   88             sender
> [  5]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec
> receiver
> 
> With our normally used DKMS module, Ethernet works with full-duplex and
> gigabit. Attached are some logs from lspci and dmesg. Do you have any
> idea how I can debug this further?

My suggestion would be:

- Look at the statistics, e.g.

   ip -s li sh dev enp2s0

- apply
  https://lore.kernel.org/r/E1vgtBc-00000005D6v-040n@rmk-PC.armlinux.org.uk
  to enable more statistics to work, and check the network driver
  statistics:

   ethtool --statistics enp2s0

to see if there's any clues for what is going on.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Georg Gottleuber]

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

Hi,

thanks for the quick reply.

Am 19.01.26 um 16:43 schrieb Russell King (Oracle):
> On Mon, Jan 19, 2026 at 04:33:17PM +0100, Georg Gottleuber wrote:
>> Hi,
>>
>> I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
>> revealed that tx is only 100Mbit/s:
>>
...
>>
>> With our normally used DKMS module, Ethernet works with full-duplex and
>> gigabit. Attached are some logs from lspci and dmesg. Do you have any
>> idea how I can debug this further?
> 
> My suggestion would be:
> 
> - Look at the statistics, e.g.
> 
>    ip -s li sh dev enp2s0

That looks good (after iperf):

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 1000
    link/ether ba:90:88:24:49:4f brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
       2091654   31556      0       0       0       0
    TX:  bytes packets errors dropped carrier collsns
      88532451    1518      0       0       0       0


> - apply
>   https://lore.kernel.org/r/E1vgtBc-00000005D6v-040n@rmk-PC.armlinux.org.uk
>   to enable more statistics to work, and check the network driver
>   statistics:
> 
>    ethtool --statistics enp2s0
> 
> to see if there's any clues for what is going on.

That looks also good, I think. I saved it before and after the test with
iperf. See attachments.

Regards,
Georg

[-- Attachment #2: ethtool_stats_after.txt --]
[-- Type: text/plain, Size: 6557 bytes --]

NIC statistics:
     ATPES: 0
     TPES: 0
     RDPES: 0
     MPES: 0
     MTSPES: 0
     ARPES: 0
     CWPES: 0
     ASRPES: 0
     TTES: 0
     RTES: 0
     CTES: 0
     ATES: 0
     PTES: 0
     T125ES: 0
     R125ES: 0
     RVCTES: 0
     MSTTES: 0
     SLVTES: 0
     ATITES: 0
     ARITES: 0
     FSMPES: 0
     TXCES: 0
     TXAMS: 0
     TXUES: 0
     RXCES: 0
     RXAMS: 0
     RXUES: 0
     ECES: 0
     EAMS: 0
     EUES: 0
     RPCES: 0
     RPAMS: 0
     RPUES: 0
     TCES: 0
     TAMS: 0
     TUES: 0
     mmc_tx_octetcount_gb: 92714511
     mmc_tx_framecount_gb: 61171
     mmc_tx_broadcastframe_g: 10
     mmc_tx_multicastframe_g: 50
     mmc_tx_64_octets_gb: 17
     mmc_tx_65_to_127_octets_gb: 62
     mmc_tx_128_to_255_octets_gb: 16
     mmc_tx_256_to_511_octets_gb: 5
     mmc_tx_512_to_1023_octets_gb: 3
     mmc_tx_1024_to_max_octets_gb: 61068
     mmc_tx_unicast_gb: 61111
     mmc_tx_multicast_gb: 50
     mmc_tx_broadcast_gb: 10
     mmc_tx_underflow_error: 0
     mmc_tx_singlecol_g: 0
     mmc_tx_multicol_g: 0
     mmc_tx_deferred: 0
     mmc_tx_latecol: 0
     mmc_tx_exesscol: 0
     mmc_tx_carrier_error: 0
     mmc_tx_octetcount_g: 92714511
     mmc_tx_framecount_g: 61171
     mmc_tx_excessdef: 0
     mmc_tx_pause_frame: 0
     mmc_tx_vlan_frame_g: 0
     mmc_tx_oversize_g: 0
     mmc_tx_lpi_usec: 0
     mmc_tx_lpi_tran: 0
     mmc_rx_framecount_gb: 31556
     mmc_rx_octetcount_gb: 2217878
     mmc_rx_octetcount_g: 2217878
     mmc_rx_broadcastframe_g: 2
     mmc_rx_multicastframe_g: 5
     mmc_rx_crc_error: 0
     mmc_rx_align_error: 0
     mmc_rx_run_error: 0
     mmc_rx_jabber_error: 0
     mmc_rx_undersize_g: 0
     mmc_rx_oversize_g: 0
     mmc_rx_64_octets_gb: 55
     mmc_rx_65_to_127_octets_gb: 31484
     mmc_rx_128_to_255_octets_gb: 4
     mmc_rx_256_to_511_octets_gb: 7
     mmc_rx_512_to_1023_octets_gb: 3
     mmc_rx_1024_to_max_octets_gb: 3
     mmc_rx_unicast_g: 31549
     mmc_rx_length_error: 0
     mmc_rx_autofrangetype: 0
     mmc_rx_pause_frames: 0
     mmc_rx_fifo_overflow: 0
     mmc_rx_vlan_frames_gb: 0
     mmc_rx_watchdog_error: 0
     mmc_rx_error: 0
     mmc_rx_lpi_usec: 0
     mmc_rx_lpi_tran: 0
     mmc_rx_discard_frames_gb: 0
     mmc_rx_discard_octets_gb: 0
     mmc_rx_align_err_frames: 0
     mmc_rx_ipv4_gd: 31543
     mmc_rx_ipv4_hderr: 0
     mmc_rx_ipv4_nopay: 0
     mmc_rx_ipv4_frag: 0
     mmc_rx_ipv4_udsbl: 0
     mmc_rx_ipv4_gd_octets: 1648664
     mmc_rx_ipv4_hderr_octets: 0
     mmc_rx_ipv4_nopay_octets: 0
     mmc_rx_ipv4_frag_octets: 0
     mmc_rx_ipv4_udsbl_octets: 0
     mmc_rx_ipv6_gd_octets: 508
     mmc_rx_ipv6_hderr_octets: 0
     mmc_rx_ipv6_nopay_octets: 0
     mmc_rx_ipv6_gd: 4
     mmc_rx_ipv6_hderr: 0
     mmc_rx_ipv6_nopay: 0
     mmc_rx_udp_gd: 18
     mmc_rx_udp_err: 0
     mmc_rx_tcp_gd: 31526
     mmc_rx_tcp_err: 0
     mmc_rx_icmp_gd: 3
     mmc_rx_icmp_err: 0
     mmc_rx_udp_gd_octets: 2951
     mmc_rx_udp_err_octets: 0
     mmc_rx_tcp_gd_octets: 1015133
     mmc_rx_tcp_err_octets: 0
     mmc_rx_icmp_gd_octets: 64
     mmc_rx_icmp_err_octets: 0
     mmc_sgf_pass_fragment_cntr: 0
     mmc_sgf_fail_fragment_cntr: 0
     mmc_tx_fpe_fragment_cntr: 0
     mmc_tx_hold_req_cntr: 0
     mmc_tx_gate_overrun_cntr: 0
     mmc_rx_packet_assembly_err_cntr: 0
     mmc_rx_packet_smd_err_cntr: 0
     mmc_rx_packet_assembly_ok_cntr: 0
     mmc_rx_fpe_fragment_cntr: 0
     tx_underflow: 0
     tx_carrier: 0
     tx_losscarrier: 0
     vlan_tag: 0
     tx_deferred: 99
     tx_vlan: 0
     tx_jabber: 0
     tx_frame_flushed: 0
     tx_payload_error: 0
     tx_ip_header_error: 0
     rx_desc: 0
     sa_filter_fail: 0
     overflow_error: 0
     ipc_csum_error: 0
     rx_collision: 0
     rx_crc_errors: 0
     dribbling_bit: 0
     rx_length: 0
     rx_mii: 0
     rx_multicast: 0
     rx_gmac_overflow: 0
     rx_watchdog: 0
     da_rx_filter_fail: 0
     sa_rx_filter_fail: 0
     rx_missed_cntr: 0
     rx_overflow_cntr: 0
     rx_vlan: 0
     rx_split_hdr_pkt_n: 31556
     tx_undeflow_irq: 0
     tx_process_stopped_irq: 0
     tx_jabber_irq: 0
     rx_overflow_irq: 0
     rx_buf_unav_irq: 0
     rx_process_stopped_irq: 0
     rx_watchdog_irq: 0
     tx_early_irq: 0
     fatal_bus_error_irq: 0
     rx_early_irq: 24
     threshold: 1
     irq_receive_pmt_irq_n: 0
     mmc_tx_irq_n: 0
     mmc_rx_irq_n: 0
     mmc_rx_csum_offload_irq_n: 0
     irq_tx_path_in_lpi_mode_n: 0
     irq_tx_path_exit_lpi_mode_n: 0
     irq_rx_path_in_lpi_mode_n: 0
     irq_rx_path_exit_lpi_mode_n: 0
     phy_eee_wakeup_error_n: 0
     ip_hdr_err: 0
     ip_payload_err: 0
     ip_csum_bypassed: 9
     ipv4_pkt_rcvd: 31543
     ipv6_pkt_rcvd: 4
     no_ptp_rx_msg_type_ext: 31556
     ptp_rx_msg_type_sync: 0
     ptp_rx_msg_type_follow_up: 0
     ptp_rx_msg_type_delay_req: 0
     ptp_rx_msg_type_delay_resp: 0
     ptp_rx_msg_type_pdelay_req: 0
     ptp_rx_msg_type_pdelay_resp: 0
     ptp_rx_msg_type_pdelay_follow_up: 0
     ptp_rx_msg_type_announce: 0
     ptp_rx_msg_type_management: 0
     ptp_rx_msg_pkt_reserved_type: 0
     ptp_frame_type: 0
     ptp_ver: 0
     timestamp_dropped: 0
     av_pkt_rcvd: 0
     av_tagged_pkt_rcvd: 0
     vlan_tag_priority_val: 0
     l3_filter_match: 0
     l4_filter_match: 0
     l3_l4_filter_no_match: 4
     irq_pcs_ane_n: 0
     irq_pcs_link_n: 0
     irq_rgmii_n: 0
     mtl_tx_status_fifo_full: 0
     mtl_tx_fifo_not_empty: 0
     mmtl_fifo_ctrl: 0
     mtl_tx_fifo_read_ctrl_write: 0
     mtl_tx_fifo_read_ctrl_wait: 0
     mtl_tx_fifo_read_ctrl_read: 0
     mtl_tx_fifo_read_ctrl_idle: 0
     mac_tx_in_pause: 0
     mac_tx_frame_ctrl_xfer: 0
     mac_tx_frame_ctrl_idle: 0
     mac_tx_frame_ctrl_wait: 0
     mac_tx_frame_ctrl_pause: 0
     mac_gmii_tx_proto_engine: 0
     mtl_rx_fifo_fill_level_full: 0
     mtl_rx_fifo_fill_above_thresh: 0
     mtl_rx_fifo_fill_below_thresh: 0
     mtl_rx_fifo_fill_level_empty: 0
     mtl_rx_fifo_read_ctrl_flush: 0
     mtl_rx_fifo_read_ctrl_read_data: 0
     mtl_rx_fifo_read_ctrl_status: 0
     mtl_rx_fifo_read_ctrl_idle: 0
     mtl_rx_fifo_ctrl_active: 0
     mac_rx_frame_ctrl_fifo: 0
     mac_gmii_rx_proto_engine: 0
     mtl_est_cgce: 0
     mtl_est_hlbs: 0
     mtl_est_hlbf: 0
     mtl_est_btre: 0
     mtl_est_btrlm: 0
     rx_pkt_n: 31556
     rx_normal_irq_n: 17408
     tx_pkt_n: 1518
     tx_normal_irq_n: 359
     tx_clean: 1766
     tx_set_ic_bit: 358
     tx_tso_frames: 1413
     tx_tso_nfrags: 4110
     normal_irq_n: 17791
     napi_poll: 19174
     q0_tx_pkt_n: 1518
     q0_tx_irq_n: 359
     q0_rx_pkt_n: 31556
     q0_rx_irq_n: 17408

[-- Attachment #3: ethtool_stats_before.txt --]
[-- Type: text/plain, Size: 6464 bytes --]

NIC statistics:
     ATPES: 0
     TPES: 0
     RDPES: 0
     MPES: 0
     MTSPES: 0
     ARPES: 0
     CWPES: 0
     ASRPES: 0
     TTES: 0
     RTES: 0
     CTES: 0
     ATES: 0
     PTES: 0
     T125ES: 0
     R125ES: 0
     RVCTES: 0
     MSTTES: 0
     SLVTES: 0
     ATITES: 0
     ARITES: 0
     FSMPES: 0
     TXCES: 0
     TXAMS: 0
     TXUES: 0
     RXCES: 0
     RXAMS: 0
     RXUES: 0
     ECES: 0
     EAMS: 0
     EUES: 0
     RPCES: 0
     RPAMS: 0
     RPUES: 0
     TCES: 0
     TAMS: 0
     TUES: 0
     mmc_tx_octetcount_gb: 16912
     mmc_tx_framecount_gb: 81
     mmc_tx_broadcastframe_g: 9
     mmc_tx_multicastframe_g: 50
     mmc_tx_64_octets_gb: 14
     mmc_tx_65_to_127_octets_gb: 41
     mmc_tx_128_to_255_octets_gb: 15
     mmc_tx_256_to_511_octets_gb: 4
     mmc_tx_512_to_1023_octets_gb: 3
     mmc_tx_1024_to_max_octets_gb: 4
     mmc_tx_unicast_gb: 22
     mmc_tx_multicast_gb: 50
     mmc_tx_broadcast_gb: 9
     mmc_tx_underflow_error: 0
     mmc_tx_singlecol_g: 0
     mmc_tx_multicol_g: 0
     mmc_tx_deferred: 0
     mmc_tx_latecol: 0
     mmc_tx_exesscol: 0
     mmc_tx_carrier_error: 0
     mmc_tx_octetcount_g: 16912
     mmc_tx_framecount_g: 81
     mmc_tx_excessdef: 0
     mmc_tx_pause_frame: 0
     mmc_tx_vlan_frame_g: 0
     mmc_tx_oversize_g: 0
     mmc_tx_lpi_usec: 0
     mmc_tx_lpi_tran: 0
     mmc_rx_framecount_gb: 34
     mmc_rx_octetcount_gb: 11181
     mmc_rx_octetcount_g: 11181
     mmc_rx_broadcastframe_g: 2
     mmc_rx_multicastframe_g: 5
     mmc_rx_crc_error: 0
     mmc_rx_align_error: 0
     mmc_rx_run_error: 0
     mmc_rx_jabber_error: 0
     mmc_rx_undersize_g: 0
     mmc_rx_oversize_g: 0
     mmc_rx_64_octets_gb: 7
     mmc_rx_65_to_127_octets_gb: 11
     mmc_rx_128_to_255_octets_gb: 4
     mmc_rx_256_to_511_octets_gb: 6
     mmc_rx_512_to_1023_octets_gb: 3
     mmc_rx_1024_to_max_octets_gb: 3
     mmc_rx_unicast_g: 27
     mmc_rx_length_error: 0
     mmc_rx_autofrangetype: 0
     mmc_rx_pause_frames: 0
     mmc_rx_fifo_overflow: 0
     mmc_rx_vlan_frames_gb: 0
     mmc_rx_watchdog_error: 0
     mmc_rx_error: 0
     mmc_rx_lpi_usec: 0
     mmc_rx_lpi_tran: 0
     mmc_rx_discard_frames_gb: 0
     mmc_rx_discard_octets_gb: 0
     mmc_rx_align_err_frames: 0
     mmc_rx_ipv4_gd: 24
     mmc_rx_ipv4_hderr: 0
     mmc_rx_ipv4_nopay: 0
     mmc_rx_ipv4_frag: 0
     mmc_rx_ipv4_udsbl: 0
     mmc_rx_ipv4_gd_octets: 9771
     mmc_rx_ipv4_hderr_octets: 0
     mmc_rx_ipv4_nopay_octets: 0
     mmc_rx_ipv4_frag_octets: 0
     mmc_rx_ipv4_udsbl_octets: 0
     mmc_rx_ipv6_gd_octets: 508
     mmc_rx_ipv6_hderr_octets: 0
     mmc_rx_ipv6_nopay_octets: 0
     mmc_rx_ipv6_gd: 4
     mmc_rx_ipv6_hderr: 0
     mmc_rx_ipv6_nopay: 0
     mmc_rx_udp_gd: 15
     mmc_rx_udp_err: 0
     mmc_rx_tcp_gd: 10
     mmc_rx_tcp_err: 0
     mmc_rx_icmp_gd: 3
     mmc_rx_icmp_err: 0
     mmc_rx_udp_gd_octets: 2728
     mmc_rx_udp_err_octets: 0
     mmc_rx_tcp_gd_octets: 6843
     mmc_rx_tcp_err_octets: 0
     mmc_rx_icmp_gd_octets: 64
     mmc_rx_icmp_err_octets: 0
     mmc_sgf_pass_fragment_cntr: 0
     mmc_sgf_fail_fragment_cntr: 0
     mmc_tx_fpe_fragment_cntr: 0
     mmc_tx_hold_req_cntr: 0
     mmc_tx_gate_overrun_cntr: 0
     mmc_rx_packet_assembly_err_cntr: 0
     mmc_rx_packet_smd_err_cntr: 0
     mmc_rx_packet_assembly_ok_cntr: 0
     mmc_rx_fpe_fragment_cntr: 0
     tx_underflow: 0
     tx_carrier: 0
     tx_losscarrier: 0
     vlan_tag: 0
     tx_deferred: 74
     tx_vlan: 0
     tx_jabber: 0
     tx_frame_flushed: 0
     tx_payload_error: 0
     tx_ip_header_error: 0
     rx_desc: 0
     sa_filter_fail: 0
     overflow_error: 0
     ipc_csum_error: 0
     rx_collision: 0
     rx_crc_errors: 0
     dribbling_bit: 0
     rx_length: 0
     rx_mii: 0
     rx_multicast: 0
     rx_gmac_overflow: 0
     rx_watchdog: 0
     da_rx_filter_fail: 0
     sa_rx_filter_fail: 0
     rx_missed_cntr: 0
     rx_overflow_cntr: 0
     rx_vlan: 0
     rx_split_hdr_pkt_n: 34
     tx_undeflow_irq: 0
     tx_process_stopped_irq: 0
     tx_jabber_irq: 0
     rx_overflow_irq: 0
     rx_buf_unav_irq: 0
     rx_process_stopped_irq: 0
     rx_watchdog_irq: 0
     tx_early_irq: 0
     fatal_bus_error_irq: 0
     rx_early_irq: 0
     threshold: 1
     irq_receive_pmt_irq_n: 0
     mmc_tx_irq_n: 0
     mmc_rx_irq_n: 0
     mmc_rx_csum_offload_irq_n: 0
     irq_tx_path_in_lpi_mode_n: 0
     irq_tx_path_exit_lpi_mode_n: 0
     irq_rx_path_in_lpi_mode_n: 0
     irq_rx_path_exit_lpi_mode_n: 0
     phy_eee_wakeup_error_n: 0
     ip_hdr_err: 0
     ip_payload_err: 0
     ip_csum_bypassed: 6
     ipv4_pkt_rcvd: 24
     ipv6_pkt_rcvd: 4
     no_ptp_rx_msg_type_ext: 34
     ptp_rx_msg_type_sync: 0
     ptp_rx_msg_type_follow_up: 0
     ptp_rx_msg_type_delay_req: 0
     ptp_rx_msg_type_delay_resp: 0
     ptp_rx_msg_type_pdelay_req: 0
     ptp_rx_msg_type_pdelay_resp: 0
     ptp_rx_msg_type_pdelay_follow_up: 0
     ptp_rx_msg_type_announce: 0
     ptp_rx_msg_type_management: 0
     ptp_rx_msg_pkt_reserved_type: 0
     ptp_frame_type: 0
     ptp_ver: 0
     timestamp_dropped: 0
     av_pkt_rcvd: 0
     av_tagged_pkt_rcvd: 0
     vlan_tag_priority_val: 0
     l3_filter_match: 0
     l4_filter_match: 0
     l3_l4_filter_no_match: 4
     irq_pcs_ane_n: 0
     irq_pcs_link_n: 0
     irq_rgmii_n: 0
     mtl_tx_status_fifo_full: 0
     mtl_tx_fifo_not_empty: 0
     mmtl_fifo_ctrl: 0
     mtl_tx_fifo_read_ctrl_write: 0
     mtl_tx_fifo_read_ctrl_wait: 0
     mtl_tx_fifo_read_ctrl_read: 0
     mtl_tx_fifo_read_ctrl_idle: 0
     mac_tx_in_pause: 0
     mac_tx_frame_ctrl_xfer: 0
     mac_tx_frame_ctrl_idle: 0
     mac_tx_frame_ctrl_wait: 0
     mac_tx_frame_ctrl_pause: 0
     mac_gmii_tx_proto_engine: 0
     mtl_rx_fifo_fill_level_full: 0
     mtl_rx_fifo_fill_above_thresh: 0
     mtl_rx_fifo_fill_below_thresh: 0
     mtl_rx_fifo_fill_level_empty: 0
     mtl_rx_fifo_read_ctrl_flush: 0
     mtl_rx_fifo_read_ctrl_read_data: 0
     mtl_rx_fifo_read_ctrl_status: 0
     mtl_rx_fifo_read_ctrl_idle: 0
     mtl_rx_fifo_ctrl_active: 0
     mac_rx_frame_ctrl_fifo: 0
     mac_gmii_rx_proto_engine: 0
     mtl_est_cgce: 0
     mtl_est_hlbs: 0
     mtl_est_hlbf: 0
     mtl_est_btre: 0
     mtl_est_btrlm: 0
     rx_pkt_n: 34
     rx_normal_irq_n: 27
     tx_pkt_n: 80
     tx_normal_irq_n: 3
     tx_clean: 62
     tx_set_ic_bit: 3
     tx_tso_frames: 1
     tx_tso_nfrags: 1
     normal_irq_n: 30
     napi_poll: 89
     q0_tx_pkt_n: 80
     q0_tx_irq_n: 3
     q0_rx_pkt_n: 34
     q0_rx_irq_n: 27

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Georg Gottleuber]

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

Am 19.01.26 um 18:45 schrieb Georg Gottleuber:
> Hi,
> 
> thanks for the quick reply.
> 
> Am 19.01.26 um 16:43 schrieb Russell King (Oracle):
>> On Mon, Jan 19, 2026 at 04:33:17PM +0100, Georg Gottleuber wrote:
>>> Hi,
>>>
>>> I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
>>> revealed that tx is only 100Mbit/s:
>>>
> ...
>>>
>>> With our normally used DKMS module, Ethernet works with full-duplex and
>>> gigabit. Attached are some logs from lspci and dmesg. Do you have any
>>> idea how I can debug this further?
>>
>> My suggestion would be:
>>
>> - Look at the statistics, e.g.
>>
>>    ip -s li sh dev enp2s0
> 
> That looks good (after iperf):
> 
> 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> mode DEFAULT group default qlen 1000
>     link/ether ba:90:88:24:49:4f brd ff:ff:ff:ff:ff:ff
>     RX:  bytes packets errors dropped  missed   mcast
>        2091654   31556      0       0       0       0
>     TX:  bytes packets errors dropped carrier collsns
>       88532451    1518      0       0       0       0
> 
> 
>> - apply
>>   https://lore.kernel.org/r/E1vgtBc-00000005D6v-040n@rmk-PC.armlinux.org.uk
>>   to enable more statistics to work, and check the network driver
>>   statistics:
>>
>>    ethtool --statistics enp2s0
>>
>> to see if there's any clues for what is going on.
> 
> That looks also good, I think. I saved it before and after the test with
> iperf. See attachments.

Oh, there was something else interesting in dmesg. See attachment.

> Regards,
> Georg

[-- Attachment #2: dmesg_motorcomm.txt --]
[-- Type: text/plain, Size: 1822 bytes --]

[    0.933480] dwmac-motorcomm 0000:02:00.0: error -ENOENT: failed to read maca0lr from eFuse
[    0.933483] dwmac-motorcomm 0000:02:00.0: eFuse contains no valid MAC address
[    0.933485] dwmac-motorcomm 0000:02:00.0: fallback to random MAC address
[    0.933941] dwmac-motorcomm 0000:02:00.0: User ID: 0x10, Synopsys ID: 0x52
[    0.933943] dwmac-motorcomm 0000:02:00.0: 	DWMAC4/5
[    0.933955] dwmac-motorcomm 0000:02:00.0: DMA HW capability register supported
[    0.933956] dwmac-motorcomm 0000:02:00.0: RX Checksum Offload Engine supported
[    0.933957] dwmac-motorcomm 0000:02:00.0: TX Checksum insertion supported
[    0.933958] dwmac-motorcomm 0000:02:00.0: Wake-Up On Lan supported
[    0.933961] dwmac-motorcomm 0000:02:00.0: TSO supported
[    0.933962] dwmac-motorcomm 0000:02:00.0: Enable RX Mitigation via HW Watchdog Timer
[    0.933964] dwmac-motorcomm 0000:02:00.0: Enabled L3L4 Flow TC (entries=2)
[    0.933965] dwmac-motorcomm 0000:02:00.0: Enabled RFS Flow TC (entries=10)
[    0.933966] dwmac-motorcomm 0000:02:00.0: TSO feature enabled
[    0.933967] dwmac-motorcomm 0000:02:00.0: SPH feature enabled
[    0.933968] dwmac-motorcomm 0000:02:00.0: Using 48/48 bits DMA host/device width
[    1.302014] dwmac-motorcomm 0000:02:00.0 enp2s0: renamed from eth0
[    5.753259] dwmac-motorcomm 0000:02:00.0 enp2s0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    5.757529] dwmac-motorcomm 0000:02:00.0 enp2s0: PHY [stmmac-200:00] driver [YT8531S Gigabit Ethernet] (irq=POLL)
[    5.768442] dwmac-motorcomm 0000:02:00.0 enp2s0: Enabling Safety Features
[    5.768669] dwmac-motorcomm 0000:02:00.0 enp2s0: PTP not supported by HW
[    5.768673] dwmac-motorcomm 0000:02:00.0 enp2s0: configuring for phy/gmii link mode
[    8.847009] dwmac-motorcomm 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control rx/tx

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Yao Zi]

On Mon, Jan 19, 2026 at 06:57:48PM +0100, Georg Gottleuber wrote:
> Am 19.01.26 um 18:45 schrieb Georg Gottleuber:
> > Hi,
> > 
> > thanks for the quick reply.
> > 
> > Am 19.01.26 um 16:43 schrieb Russell King (Oracle):
> >> On Mon, Jan 19, 2026 at 04:33:17PM +0100, Georg Gottleuber wrote:
> >>> Hi,
> >>>
> >>> I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
> >>> revealed that tx is only 100Mbit/s:
> >>>
> > ...
> >>>
> >>> With our normally used DKMS module, Ethernet works with full-duplex and
> >>> gigabit. Attached are some logs from lspci and dmesg. Do you have any
> >>> idea how I can debug this further?
> >>
> >> My suggestion would be:
> >>
> >> - Look at the statistics, e.g.
> >>
> >>    ip -s li sh dev enp2s0
> > 
> > That looks good (after iperf):
> > 
> > 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> > mode DEFAULT group default qlen 1000
> >     link/ether ba:90:88:24:49:4f brd ff:ff:ff:ff:ff:ff
> >     RX:  bytes packets errors dropped  missed   mcast
> >        2091654   31556      0       0       0       0
> >     TX:  bytes packets errors dropped carrier collsns
> >       88532451    1518      0       0       0       0
> > 
> > 
> >> - apply
> >>   https://lore.kernel.org/r/E1vgtBc-00000005D6v-040n@rmk-PC.armlinux.org.uk
> >>   to enable more statistics to work, and check the network driver
> >>   statistics:
> >>
> >>    ethtool --statistics enp2s0
> >>
> >> to see if there's any clues for what is going on.
> > 
> > That looks also good, I think. I saved it before and after the test with
> > iperf. See attachments.
> 
> Oh, there was something else interesting in dmesg. See attachment.
> 
> > Regards,
> > Georg

> [    0.933480] dwmac-motorcomm 0000:02:00.0: error -ENOENT: failed to read maca0lr from eFuse
> [    0.933483] dwmac-motorcomm 0000:02:00.0: eFuse contains no valid MAC address
> [    0.933485] dwmac-motorcomm 0000:02:00.0: fallback to random MAC address

Some vendors didn't write a MAC address to the eFuse. With these YT6801
chips, the failure is expected.

Which DKMS driver do you use? Could you read out a permanent address
with your DKMS driver? If not, this piece of log should have nothing to
do with the rate problem.

Note some out-of-tree driver derived from the vendor one fallback to a
static MAC address[1], so it doesn't mean your eFuse has MAC address
written if you only observe the MAC address doesn't change between
reboots.

Best regards,
Yao Zi

[1]: https://github.com/ziyao233/yt6801-vendor-driver/blob/0efb3e86702ad2b19e7f9d19172a8e1df143e8c7/fuxi-gmac-common.c#L17-L32

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Georg Gottleuber]

Am 20.01.26 um 03:45 schrieb Yao Zi:
> On Mon, Jan 19, 2026 at 06:57:48PM +0100, Georg Gottleuber wrote:
>> Am 19.01.26 um 18:45 schrieb Georg Gottleuber:
>>> Hi,
>>>
>>> thanks for the quick reply.
>>>
>>> Am 19.01.26 um 16:43 schrieb Russell King (Oracle):
>>>> On Mon, Jan 19, 2026 at 04:33:17PM +0100, Georg Gottleuber wrote:
>>>>> Hi,
>>>>>
>>>>> I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
>>>>> revealed that tx is only 100Mbit/s:
>>>>>
>>> ...
>>>>>
>>>>> With our normally used DKMS module, Ethernet works with full-duplex and
>>>>> gigabit. Attached are some logs from lspci and dmesg. Do you have any
>>>>> idea how I can debug this further?
>>>>
>>>> My suggestion would be:
>>>>
>>>> - Look at the statistics, e.g.
>>>>
>>>>    ip -s li sh dev enp2s0
>>>
>>> That looks good (after iperf):
>>>
>>> 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
>>> mode DEFAULT group default qlen 1000
>>>     link/ether ba:90:88:24:49:4f brd ff:ff:ff:ff:ff:ff
>>>     RX:  bytes packets errors dropped  missed   mcast
>>>        2091654   31556      0       0       0       0
>>>     TX:  bytes packets errors dropped carrier collsns
>>>       88532451    1518      0       0       0       0
>>>
>>>
>>>> - apply
>>>>   https://lore.kernel.org/r/E1vgtBc-00000005D6v-040n@rmk-PC.armlinux.org.uk
>>>>   to enable more statistics to work, and check the network driver
>>>>   statistics:
>>>>
>>>>    ethtool --statistics enp2s0
>>>>
>>>> to see if there's any clues for what is going on.
>>>
>>> That looks also good, I think. I saved it before and after the test with
>>> iperf. See attachments.
>>
>> Oh, there was something else interesting in dmesg. See attachment.
>>
>>> Regards,
>>> Georg
> 
>> [    0.933480] dwmac-motorcomm 0000:02:00.0: error -ENOENT: failed to read maca0lr from eFuse
>> [    0.933483] dwmac-motorcomm 0000:02:00.0: eFuse contains no valid MAC address
>> [    0.933485] dwmac-motorcomm 0000:02:00.0: fallback to random MAC address
> 
> Some vendors didn't write a MAC address to the eFuse. With these YT6801
> chips, the failure is expected.

I believe we have a fixed address, as our DKMS driver always uses it (it
is also displayed in the BIOS).

> Which DKMS driver do you use? Could you read out a permanent address
> with your DKMS driver? If not, this piece of log should have nothing to
> do with the rate problem.

DKMS module we use:
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-yt6801

Apparently, your driver can also read the permanent address. I rebooted
nine times to test it, and it worked nine times. So it was probably a
glitch that doesn't occur very often.

Do you have any ideas on how I can further debug the rate problem?

> Note some out-of-tree driver derived from the vendor one fallback to a
> static MAC address[1], so it doesn't mean your eFuse has MAC address
> written if you only observe the MAC address doesn't change between
> reboots.
> 
> Best regards,
> Yao Zi
> 
> [1]: https://github.com/ziyao233/yt6801-vendor-driver/blob/0efb3e86702ad2b19e7f9d19172a8e1df143e8c7/fuxi-gmac-common.c#L17-L32

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Yao Zi]

On Tue, Jan 20, 2026 at 10:42:28AM +0100, Georg Gottleuber wrote:
> 
> 
> Am 20.01.26 um 03:45 schrieb Yao Zi:
> > On Mon, Jan 19, 2026 at 06:57:48PM +0100, Georg Gottleuber wrote:
> >> Am 19.01.26 um 18:45 schrieb Georg Gottleuber:
> >>> Hi,
> >>>
> >>> thanks for the quick reply.
> >>>
> >>> Am 19.01.26 um 16:43 schrieb Russell King (Oracle):
> >>>> On Mon, Jan 19, 2026 at 04:33:17PM +0100, Georg Gottleuber wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
> >>>>> revealed that tx is only 100Mbit/s:
> >>>>>
> >>> ...
> >>>>>
> >>>>> With our normally used DKMS module, Ethernet works with full-duplex and
> >>>>> gigabit. Attached are some logs from lspci and dmesg. Do you have any
> >>>>> idea how I can debug this further?
> >>>>
> >>>> My suggestion would be:
> >>>>
> >>>> - Look at the statistics, e.g.
> >>>>
> >>>>    ip -s li sh dev enp2s0
> >>>
> >>> That looks good (after iperf):
> >>>
> >>> 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> >>> mode DEFAULT group default qlen 1000
> >>>     link/ether ba:90:88:24:49:4f brd ff:ff:ff:ff:ff:ff
> >>>     RX:  bytes packets errors dropped  missed   mcast
> >>>        2091654   31556      0       0       0       0
> >>>     TX:  bytes packets errors dropped carrier collsns
> >>>       88532451    1518      0       0       0       0
> >>>
> >>>
> >>>> - apply
> >>>>   https://lore.kernel.org/r/E1vgtBc-00000005D6v-040n@rmk-PC.armlinux.org.uk
> >>>>   to enable more statistics to work, and check the network driver
> >>>>   statistics:
> >>>>
> >>>>    ethtool --statistics enp2s0
> >>>>
> >>>> to see if there's any clues for what is going on.
> >>>
> >>> That looks also good, I think. I saved it before and after the test with
> >>> iperf. See attachments.
> >>
> >> Oh, there was something else interesting in dmesg. See attachment.
> >>
> >>> Regards,
> >>> Georg
> > 
> >> [    0.933480] dwmac-motorcomm 0000:02:00.0: error -ENOENT: failed to read maca0lr from eFuse
> >> [    0.933483] dwmac-motorcomm 0000:02:00.0: eFuse contains no valid MAC address
> >> [    0.933485] dwmac-motorcomm 0000:02:00.0: fallback to random MAC address
> > 
> > Some vendors didn't write a MAC address to the eFuse. With these YT6801
> > chips, the failure is expected.
> 
> I believe we have a fixed address, as our DKMS driver always uses it (it
> is also displayed in the BIOS).
> 
> > Which DKMS driver do you use? Could you read out a permanent address
> > with your DKMS driver? If not, this piece of log should have nothing to
> > do with the rate problem.
> 
> DKMS module we use:
> https://gitlab.com/tuxedocomputers/development/packages/tuxedo-yt6801
> 
> Apparently, your driver can also read the permanent address. I rebooted
> nine times to test it, and it worked nine times. So it was probably a
> glitch that doesn't occur very often.

Thanks for the hint. I'm sure I've encountered similar cases once or
twice during development, but it stopped happening later, so I
considered it's somehow fixed. I'll test more and see what's going wrong
here.

> 
> Do you have any ideas on how I can further debug the rate problem?

Sadly I don't have any good suggestions. The Motorcomm glue is
mysterious and totally undocumented, so it's hard to find out what's
missing or wrong. I had to debug the driver by modifying this and vendor
driver and then comparing behavior differences.

Do you build the driver into the kernel, or as a module? I'll try to
reproduce your case locally and investigate it, but as a hobbyist I
cannot make any promises, really sorry about it.

Best regards,
Yao Zi

Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

[Xi Ruoyao]

On Tue, 2026-01-20 at 11:52 +0000, Yao Zi wrote:
> > > > > > > I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
> > > > > > > revealed that tx is only 100Mbit/s:
> > > > > > > 
> > > > > ...
> > > > > > > 
> > > > > > > With our normally used DKMS module, Ethernet works with full-duplex and
> > > > > > > gigabit. Attached are some logs from lspci and dmesg. Do you have any
> > > > > > > idea how I can debug this further?

Just FYI: on the contrary, the DKMS module from vendor often negotiates
to 10Mbps (for both RX and TX) on the Loongson 3A6000 and 3C6000 boards
but we've not observed any issue with the driver in this series (we also
tested with iperf).

-- 
Xi Ruoyao <xry111@xry111.site>