From: Chen-Yu Tsai <wens@csie.org>
The Allwinner A523 SoC family has a second Ethernet controller, called
the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for
numbering. This controller, according to BSP sources, is fully
compatible with a slightly newer version of the Synopsys DWMAC core.
The glue layer around the controller is the same as found around older
DWMAC cores on Allwinner SoCs. The only slight difference is that since
this is the second controller on the SoC, the register for the clock
delay controls is at a different offset. Last, the integration includes
a dedicated clock gate for the memory bus and the whole thing is put in
a separately controllable power domain.
Add a new driver for this hardware supporting the integration layer.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Changes since v5:
- Use plat->phy_interface instead of plat->mac_interface (Russell)
Changes since v3:
- Fixed printf format specifier warning
Changes since v2 (all suggested by Russell King):
- Include "ps" unit in "... must be multiple of ..." error message
- Use FIELD_FIT to check if delay value is in range and FIELD_MAX to get
the maximum value
- Reword error message for delay value exceeding maximum
- Drop MASK_TO_VAL
Changes since v1:
- Switch to generic (tx|rx)-internal-delay-ps properties
- Change dev_err() + return to dev_err_probe()
- Check return value from syscon regmap write
- Change driver name to match file name
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 12 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../ethernet/stmicro/stmmac/dwmac-sun55i.c | 159 ++++++++++++++++++
3 files changed, 172 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun55i.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 91d9a14362bf..9507131875b2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -265,6 +265,18 @@ config DWMAC_SUN8I
stmmac device driver. This driver is used for H3/A83T/A64
EMAC ethernet controller.
+config DWMAC_SUN55I
+ tristate "Allwinner sun55i GMAC200 support"
+ default ARCH_SUNXI
+ depends on OF && (ARCH_SUNXI || COMPILE_TEST)
+ select MDIO_BUS_MUX
+ help
+ Support for Allwinner A523/T527 GMAC200 ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for A523/T527
+ GMAC200 ethernet controller.
+
config DWMAC_THEAD
tristate "T-HEAD dwmac support"
depends on OF && (ARCH_THEAD || COMPILE_TEST)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index b591d93f8503..51e068e26ce4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
obj-$(CONFIG_DWMAC_STM32) += dwmac-stm32.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
obj-$(CONFIG_DWMAC_SUN8I) += dwmac-sun8i.o
+obj-$(CONFIG_DWMAC_SUN55I) += dwmac-sun55i.o
obj-$(CONFIG_DWMAC_THEAD) += dwmac-thead.o
obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
obj-$(CONFIG_DWMAC_INTEL_PLAT) += dwmac-intel-plat.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun55i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun55i.c
new file mode 100644
index 000000000000..862df173d963
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun55i.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * dwmac-sun55i.c - Allwinner sun55i GMAC200 specific glue layer
+ *
+ * Copyright (C) 2025 Chen-Yu Tsai <wens@csie.org>
+ *
+ * syscon parts taken from dwmac-sun8i.c, which is
+ *
+ * Copyright (C) 2017 Corentin Labbe <clabbe.montjoie@gmail.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/stmmac.h>
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+#define SYSCON_REG 0x34
+
+/* RMII specific bits */
+#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
+/* Generic system control EMAC_CLK bits */
+#define SYSCON_ETXDC_MASK GENMASK(12, 10)
+#define SYSCON_ERXDC_MASK GENMASK(9, 5)
+/* EMAC PHY Interface Type */
+#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
+#define SYSCON_ETCS_MASK GENMASK(1, 0)
+#define SYSCON_ETCS_MII 0x0
+#define SYSCON_ETCS_EXT_GMII 0x1
+#define SYSCON_ETCS_INT_GMII 0x2
+
+static int sun55i_gmac200_set_syscon(struct device *dev,
+ struct plat_stmmacenet_data *plat)
+{
+ struct device_node *node = dev->of_node;
+ struct regmap *regmap;
+ u32 val, reg = 0;
+ int ret;
+
+ regmap = syscon_regmap_lookup_by_phandle(node, "syscon");
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap), "Unable to map syscon\n");
+
+ if (!of_property_read_u32(node, "tx-internal-delay-ps", &val)) {
+ if (val % 100)
+ return dev_err_probe(dev, -EINVAL,
+ "tx-delay must be a multiple of 100ps\n");
+ val /= 100;
+ dev_dbg(dev, "set tx-delay to %x\n", val);
+ if (!FIELD_FIT(SYSCON_ETXDC_MASK, val))
+ return dev_err_probe(dev, -EINVAL,
+ "TX clock delay exceeds maximum (%u00ps > %lu00ps)\n",
+ val, FIELD_MAX(SYSCON_ETXDC_MASK));
+
+ reg |= FIELD_PREP(SYSCON_ETXDC_MASK, val);
+ }
+
+ if (!of_property_read_u32(node, "rx-internal-delay-ps", &val)) {
+ if (val % 100)
+ return dev_err_probe(dev, -EINVAL,
+ "rx-delay must be a multiple of 100ps\n");
+ val /= 100;
+ dev_dbg(dev, "set rx-delay to %x\n", val);
+ if (!FIELD_FIT(SYSCON_ERXDC_MASK, val))
+ return dev_err_probe(dev, -EINVAL,
+ "RX clock delay exceeds maximum (%u00ps > %lu00ps)\n",
+ val, FIELD_MAX(SYSCON_ERXDC_MASK));
+
+ reg |= FIELD_PREP(SYSCON_ERXDC_MASK, val);
+ }
+
+ switch (plat->phy_interface) {
+ case PHY_INTERFACE_MODE_MII:
+ /* default */
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ reg |= SYSCON_RMII_EN;
+ break;
+ default:
+ return dev_err_probe(dev, -EINVAL, "Unsupported interface mode: %s",
+ phy_modes(plat->phy_interface));
+ }
+
+ ret = regmap_write(regmap, SYSCON_REG, reg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to write to syscon\n");
+
+ return 0;
+}
+
+static int sun55i_gmac200_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct device *dev = &pdev->dev;
+ struct clk *clk;
+ int ret;
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = devm_stmmac_probe_config_dt(pdev, stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ /* BSP disables it */
+ plat_dat->flags |= STMMAC_FLAG_SPH_DISABLE;
+ plat_dat->host_dma_width = 32;
+
+ ret = sun55i_gmac200_set_syscon(dev, plat_dat);
+ if (ret)
+ return ret;
+
+ clk = devm_clk_get_enabled(dev, "mbus");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "Failed to get or enable MBUS clock\n");
+
+ ret = devm_regulator_get_enable_optional(dev, "phy");
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get or enable PHY supply\n");
+
+ return devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
+}
+
+static const struct of_device_id sun55i_gmac200_match[] = {
+ { .compatible = "allwinner,sun55i-a523-gmac200" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sun55i_gmac200_match);
+
+static struct platform_driver sun55i_gmac200_driver = {
+ .probe = sun55i_gmac200_probe,
+ .driver = {
+ .name = "dwmac-sun55i",
+ .pm = &stmmac_pltfr_pm_ops,
+ .of_match_table = sun55i_gmac200_match,
+ },
+};
+module_platform_driver(sun55i_gmac200_driver);
+
+MODULE_AUTHOR("Chen-Yu Tsai <wens@csie.org>");
+MODULE_DESCRIPTION("Allwinner sun55i GMAC200 specific glue layer");
+MODULE_LICENSE("GPL");
--
2.47.3On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: > The Allwinner A523 SoC family has a second Ethernet controller, called > the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for > numbering. This controller, according to BSP sources, is fully > compatible with a slightly newer version of the Synopsys DWMAC core. > The glue layer around the controller is the same as found around older > DWMAC cores on Allwinner SoCs. The only slight difference is that since > this is the second controller on the SoC, the register for the clock > delay controls is at a different offset. Last, the integration includes > a dedicated clock gate for the memory bus and the whole thing is put in > a separately controllable power domain. Hi Andrew, does this look good ? thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org
On Mon, 29 Sep 2025 18:08:04 -0700 Jakub Kicinski wrote: > On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: > > The Allwinner A523 SoC family has a second Ethernet controller, called > > the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for > > numbering. This controller, according to BSP sources, is fully > > compatible with a slightly newer version of the Synopsys DWMAC core. > > The glue layer around the controller is the same as found around older > > DWMAC cores on Allwinner SoCs. The only slight difference is that since > > this is the second controller on the SoC, the register for the clock > > delay controls is at a different offset. Last, the integration includes > > a dedicated clock gate for the memory bus and the whole thing is put in > > a separately controllable power domain. > > Hi Andrew, does this look good ? > > thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org Adding Heiner and Russell, in case Andrew is AFK. We need an ack from PHY maintainers, the patch seems to be setting delays regardless of the exact RMII mode. I don't know these things..
On Tue, Sep 30, 2025 at 05:20:22PM -0700, Jakub Kicinski wrote: > On Mon, 29 Sep 2025 18:08:04 -0700 Jakub Kicinski wrote: > > On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: > > > The Allwinner A523 SoC family has a second Ethernet controller, called > > > the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for > > > numbering. This controller, according to BSP sources, is fully > > > compatible with a slightly newer version of the Synopsys DWMAC core. > > > The glue layer around the controller is the same as found around older > > > DWMAC cores on Allwinner SoCs. The only slight difference is that since > > > this is the second controller on the SoC, the register for the clock > > > delay controls is at a different offset. Last, the integration includes > > > a dedicated clock gate for the memory bus and the whole thing is put in > > > a separately controllable power domain. > > > > Hi Andrew, does this look good ? > > > > thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org > > Adding Heiner and Russell, in case Andrew is AFK. I believe it's fine. Applying the delays irrespective of the RGMII mode is what I think needs to be done to allow the delays to be fine-tuned. The author hsa confirmed that the delays don't apply to RMII, so that isn't a concern. So, 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!
On 10/1/25 2:20 AM, Jakub Kicinski wrote: > On Mon, 29 Sep 2025 18:08:04 -0700 Jakub Kicinski wrote: >> On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: >>> The Allwinner A523 SoC family has a second Ethernet controller, called >>> the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for >>> numbering. This controller, according to BSP sources, is fully >>> compatible with a slightly newer version of the Synopsys DWMAC core. >>> The glue layer around the controller is the same as found around older >>> DWMAC cores on Allwinner SoCs. The only slight difference is that since >>> this is the second controller on the SoC, the register for the clock >>> delay controls is at a different offset. Last, the integration includes >>> a dedicated clock gate for the memory bus and the whole thing is put in >>> a separately controllable power domain. >> >> Hi Andrew, does this look good ? >> >> thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org > > Adding Heiner and Russell, in case Andrew is AFK. > > We need an ack from PHY maintainers, the patch seems to be setting > delays regardless of the exact RMII mode. I don't know these things.. The net-next PR is upon us, let's defer even this series to the next cycle. @Chen-Yu Tsai: please re-post it when net-next will reopen after Oct 12th, thanks! Paolo
On 10/1/25 9:25 AM, Paolo Abeni wrote: > On 10/1/25 2:20 AM, Jakub Kicinski wrote: >> On Mon, 29 Sep 2025 18:08:04 -0700 Jakub Kicinski wrote: >>> On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: >>>> The Allwinner A523 SoC family has a second Ethernet controller, called >>>> the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for >>>> numbering. This controller, according to BSP sources, is fully >>>> compatible with a slightly newer version of the Synopsys DWMAC core. >>>> The glue layer around the controller is the same as found around older >>>> DWMAC cores on Allwinner SoCs. The only slight difference is that since >>>> this is the second controller on the SoC, the register for the clock >>>> delay controls is at a different offset. Last, the integration includes >>>> a dedicated clock gate for the memory bus and the whole thing is put in >>>> a separately controllable power domain. >>> >>> Hi Andrew, does this look good ? >>> >>> thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org >> >> Adding Heiner and Russell, in case Andrew is AFK. >> >> We need an ack from PHY maintainers, the patch seems to be setting >> delays regardless of the exact RMII mode. I don't know these things.. > > The net-next PR is upon us, let's defer even this series to the next cycle. > > @Chen-Yu Tsai: please re-post it when net-next will reopen after Oct > 12th, thanks! To be clear: given Russell's ack I'm applying the series now, no need to repost. Thanks, Paolo
On Wed, Oct 01, 2025 at 09:25:07AM +0200, Paolo Abeni wrote: > On 10/1/25 2:20 AM, Jakub Kicinski wrote: > > On Mon, 29 Sep 2025 18:08:04 -0700 Jakub Kicinski wrote: > >> On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: > >>> The Allwinner A523 SoC family has a second Ethernet controller, called > >>> the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for > >>> numbering. This controller, according to BSP sources, is fully > >>> compatible with a slightly newer version of the Synopsys DWMAC core. > >>> The glue layer around the controller is the same as found around older > >>> DWMAC cores on Allwinner SoCs. The only slight difference is that since > >>> this is the second controller on the SoC, the register for the clock > >>> delay controls is at a different offset. Last, the integration includes > >>> a dedicated clock gate for the memory bus and the whole thing is put in > >>> a separately controllable power domain. > >> > >> Hi Andrew, does this look good ? > >> > >> thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org > > > > Adding Heiner and Russell, in case Andrew is AFK. > > > > We need an ack from PHY maintainers, the patch seems to be setting > > delays regardless of the exact RMII mode. I don't know these things.. > > The net-next PR is upon us, let's defer even this series to the next cycle. Would've been nice to have been given the opportunity to respond to Jakub's email before that decision was made. Not all of us are in the US timezone. (Jakub's email came in gone 1am my time.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 10/1/25 9:48 AM, Russell King (Oracle) wrote: > On Wed, Oct 01, 2025 at 09:25:07AM +0200, Paolo Abeni wrote: >> On 10/1/25 2:20 AM, Jakub Kicinski wrote: >>> On Mon, 29 Sep 2025 18:08:04 -0700 Jakub Kicinski wrote: >>>> On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: >>>>> The Allwinner A523 SoC family has a second Ethernet controller, called >>>>> the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for >>>>> numbering. This controller, according to BSP sources, is fully >>>>> compatible with a slightly newer version of the Synopsys DWMAC core. >>>>> The glue layer around the controller is the same as found around older >>>>> DWMAC cores on Allwinner SoCs. The only slight difference is that since >>>>> this is the second controller on the SoC, the register for the clock >>>>> delay controls is at a different offset. Last, the integration includes >>>>> a dedicated clock gate for the memory bus and the whole thing is put in >>>>> a separately controllable power domain. >>>> >>>> Hi Andrew, does this look good ? >>>> >>>> thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org >>> >>> Adding Heiner and Russell, in case Andrew is AFK. >>> >>> We need an ack from PHY maintainers, the patch seems to be setting >>> delays regardless of the exact RMII mode. I don't know these things.. >> >> The net-next PR is upon us, let's defer even this series to the next cycle. > > Would've been nice to have been given the opportunity to respond to > Jakub's email before that decision was made. Not all of us are in > the US timezone. (Jakub's email came in gone 1am my time.) I'm sorry, the time constraint is very strict. The PR is already in late. My message's goal was to give you the needed and deserve time for reviewing the series, not to pressure you. Note that to merge the series at this point I need to undo some of the work already done. Cheers, Paolo
On Wed, Oct 1, 2025 at 8:20 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Mon, 29 Sep 2025 18:08:04 -0700 Jakub Kicinski wrote: > > On Fri, 26 Sep 2025 03:15:59 +0800 Chen-Yu Tsai wrote: > > > The Allwinner A523 SoC family has a second Ethernet controller, called > > > the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for > > > numbering. This controller, according to BSP sources, is fully > > > compatible with a slightly newer version of the Synopsys DWMAC core. > > > The glue layer around the controller is the same as found around older > > > DWMAC cores on Allwinner SoCs. The only slight difference is that since > > > this is the second controller on the SoC, the register for the clock > > > delay controls is at a different offset. Last, the integration includes > > > a dedicated clock gate for the memory bus and the whole thing is put in > > > a separately controllable power domain. > > > > Hi Andrew, does this look good ? > > > > thread: https://lore.kernel.org/20250925191600.3306595-3-wens@kernel.org > > Adding Heiner and Russell, in case Andrew is AFK. > > We need an ack from PHY maintainers, the patch seems to be setting > delays regardless of the exact RMII mode. I don't know these things.. AFAIK the delays only apply to the RGMII signal path, i.e. they are no-op for RMII. Also, the delays are unrelated to the 2ns delay required by RGMII. These delays are more for tweaking minute signal length differences. ChenYu
© 2016 - 2025 Red Hat, Inc.