Re: [PATCH net-next v3 0/3] net: stmmac: add Allwinner H616 EMAC1 support
From: Alastair D'Silva <hidden>
Date: 2026-09-18 04:18:06
Also in:
linux-arm-kernel, linux-devicetree, linux-sunxi, lkml
On Thu, 2026-09-17 at 11:55 -0600, James Hilliard wrote:
The H616 secondary EMAC supports RMII at 10/100 Mbps and uses a separate system-control clock register at offset 0x34. Add its binding and a sun8i stmmac variant using that register. A distinct compatible without an older fallback prevents the driver from using EMAC0's clock register. EMAC1 connects internally to the co-packaged AC200 or AC300 EPHY and has no external PHY pins. Leave PHY initialization to the PHY driver instead of using the H3 internal-PHY controls. The RMII-only variant does not expose the RGMII clock-delay properties. First move the MAC software reset from probe to the DMA reset callback, after PHY initialization. This lets the MAC and its MDIO bus remain registered when the PHY driver or one of its suppliers is not ready yet. Keep the separate H3 MDIO-mux reset sequence unchanged. The AC200/AC300 EPHY driver and package bindings are already in net-next. This series separates the H616 EMAC1 MAC driver and binding support from the earlier combined series. PWM, MFD and device-tree enablement are being handled separately. Signed-off-by: James Hilliard <redacted> --- Changes in v3: - Add a prerequisite fix moving the MAC software reset to the DMA reset callback, after PHY initialization, so delayed module loading and deferred PHY probes do not tear down the MAC and its MDIO bus. - Preserve the H3 MDIO-mux reset and propagate hardware-reset failures through the normal stmmac hardware-setup error path. - Add Alastair D'Silva to Cc and rebase onto current net-next. - Link to v2: https://patch.msgid.link/20260915-submit-h616-emac1-v1- v2-0-322b32e40eb9@gmail.com Changes in v2: - Drop EMAC1 TX/RX clock-delay property support and keep the existing RGMII-only delay descriptions unchanged, as requested by Maxime Ripard. - Clarify that EMAC1 connects internally to a co-packaged PHY, not an external PHY or the H3-style internal-PHY controls. - Rebase onto current net-next. - Link to v1: https://patch.msgid.link/20260915-submit-h616-emac1-v1- v1-0-195de0bb1f8a@gmail.com --- James Hilliard (3): net: stmmac: sun8i: reset the MAC after PHY initialization dt-bindings: net: allwinner: add H616 EMAC1 net: stmmac: sun8i: add support for Allwinner H616 EMAC1 .../bindings/net/allwinner,sun8i-a83t-emac.yaml | 13 +++++ .../devicetree/bindings/net/snps,dwmac.yaml | 2 + drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 66 +++++++++++++--------- 3 files changed, 55 insertions(+), 26 deletions(-) --- base-commit: 26ee8cd69d46a14b37ba5e512084fe80d730127a change-id: 20260914-submit-h616-emac1-v1-143703842abb Best regards, -- James Hilliard [off-list ref]
Confirmed working on the Mellow Fly C5 when brought in as a module and backported to 6.18, tested in the Armbian environment, along with the recommended PWM patch: https://lore.kernel.org/all/20260804-h616-pwm-v8-v8-0-db37ab8624ae@gmail.com/T/ (local) root@mellowflyc5:~# lsmod Module Size Used by rtw88_8821cs 12288 0 rtw88_8821c 86016 1 rtw88_8821cs rtw88_sdio 20480 1 rtw88_8821cs rtw88_core 180224 2 rtw88_8821c,rtw88_sdio snd_soc_hdmi_codec 16384 0 mac80211 929792 2 rtw88_sdio,rtw88_core zram 36864 2 842_decompress 12288 1 zram 842_compress 16384 1 zram gs_usb 20480 0 can_dev 36864 1 gs_usb dw_hdmi_i2s_audio 12288 0 dw_hdmi_cec 12288 0 cdc_acm 32768 0 sun50i_h6_prcm_ppu 12288 0 panfrost 73728 0 governor_simpleondemand 12288 0 gpu_sched 45056 1 panfrost sun8i_ce 36864 0 drm_shmem_helper 24576 1 panfrost crypto_engine 12288 1 sun8i_ce cfg80211 831488 2 rtw88_core,mac80211 binfmt_misc 16384 1 rfkill 24576 2 cfg80211 sch_fq_codel 16384 2 fuse 163840 1 configfs 40960 1 nfnetlink 16384 2 ip_tables 24576 0 x_tables 28672 1 ip_tables btrfs 1441792 0 blake2b_generic 16384 0 xor 12288 1 btrfs raid6_pq 94208 1 btrfs ac300_phy 12288 1 ac200_phy 12288 0 dwmac_sun8i 20480 0 root@mellowflyc5:~# uname -a Linux mellowflyc5 6.18.52-current-sunxi64 #27 SMP PREEMPT Mon Sep 14 21:36:19 AEST 2026 aarch64 GNU/Linux root@mellowflyc5:~# ifconfig end0 end0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.1.136 netmask 255.255.255.0 broadcast 10.0.1.255 inet6 fe80::9aff:fea2:59e8 prefixlen 64 scopeid 0x20<link> ether 02:00:9a:a2:59:e8 txqueuelen 1000 (Ethernet) RX packets 5202 bytes 941999 (919.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 4059 bytes 431730 (421.6 KiB) TX errors 0 dropped 5 overruns 0 carrier 0 collisions 0 device interrupt 50 root@mellowflyc5:~# iperf3 -c 10.0.1.1 Connecting to host 10.0.1.1, port 5201 [ 5] local 10.0.1.136 port 53578 connected to 10.0.1.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 12.0 MBytes 101 Mbits/sec 0 191 KBytes [ 5] 1.00-2.00 sec 11.5 MBytes 96.5 Mbits/sec 0 191 KBytes [ 5] 2.00-3.00 sec 11.1 MBytes 93.3 Mbits/sec 0 191 KBytes [ 5] 3.00-4.00 sec 11.2 MBytes 94.4 Mbits/sec 0 191 KBytes [ 5] 4.00-5.00 sec 11.2 MBytes 94.4 Mbits/sec 0 191 KBytes [ 5] 5.00-6.00 sec 11.1 MBytes 93.3 Mbits/sec 0 191 KBytes [ 5] 6.00-7.00 sec 11.4 MBytes 95.4 Mbits/sec 0 191 KBytes [ 5] 7.00-8.00 sec 11.2 MBytes 94.3 Mbits/sec 0 191 KBytes [ 5] 8.00-9.00 sec 11.2 MBytes 94.4 Mbits/sec 0 191 KBytes [ 5] 9.00-10.00 sec 11.1 MBytes 93.2 Mbits/sec 0 191 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 113 MBytes 95.0 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 112 MBytes 94.1 Mbits/sec receiver iperf Done. I did notice that the speed and activity LEDs on the magjack remained dark. LED Output Pad Enables (Register 0x05 - SYS_IO) ----------------------------------------------- According to the AC300 datasheet (Section 4.2.5), bits [3:1] default to 0 (disabled): - Bit 1: E_LNK_LED_IO_EN - Bit 2: E_SPD_LED_IO_EN - Bit 3: E_DPX_LED_IO_EN In drivers/net/phy/xpowers/ac300.c, AC300_SYS_IO_VALUE does not set any of these bits. Consequently, the LED outputs remain disabled/tri- stated, and neither the link nor speed LEDs illuminate on the board. LED Polarity (Register 0x06 - EPHY_CONFIG) ------------------------------------------ Once the I/O pads are enabled, Register 0x06 bit 1 (LED_POL) controls the drive logic: - Bit 1 = 0: Active-High (Default) - Bit 1 = 1: Active-Low Because common RJ45 magjacks (such as the HY911105AE on Fly-C5, Orange Pi Zero 2W/3, etc.) have LED anodes connected to 3.3V, the PHY must sink current (Active-Low) to drive them. Without setting LED_POL = 1, the LED logic is inverted. Could we update AC300_SYS_IO_VALUE to enable the LED IO pads, and configure LED_POL for active-low operation (or wire it up to the phylib LED framework)? Suggested patch for drivers/net/phy/xpowers/ac300.c:
--- a/drivers/net/phy/xpowers/ac300.c
+++ b/drivers/net/phy/xpowers/ac300.c@@ -43,10 +43,14 @@ #define AC300_IO_DRV_LEVEL_2 2 #define AC300_CLKIN_PAD_ENABLE BIT(4) +#define AC300_EPHY_DPX_LED_IO_ENABLE BIT(3) +#define AC300_EPHY_SPD_LED_IO_ENABLE BIT(2) +#define AC300_EPHY_LNK_LED_IO_ENABLE BIT(1) #define AC300_EPHY_MII_IO_ENABLE BIT(0) #define AC300_EPHY_CONFIG_REG 0x06 #define AC300_EPHY_BGS_EFFUSE_MASK GENMASK(15, 12) #define AC300_EPHY_RMII_SEL BIT(11) +#define AC300_EPHY_LED_POL_ACTIVE_LOW BIT(1) #define AC300_EPHY_SHUTDOWN BIT(0)
@@ -58,7 +62,10 @@ #define AC300_SYS_IO_VALUE \ (FIELD_PREP(AC300_MDIO_DRV_MASK, AC300_IO_DRV_LEVEL_2) | \ FIELD_PREP(AC300_MII_DRV_MASK, AC300_IO_DRV_LEVEL_2) | \ - AC300_CLKIN_PAD_ENABLE | AC300_EPHY_MII_IO_ENABLE) + AC300_CLKIN_PAD_ENABLE | AC300_EPHY_MII_IO_ENABLE | \ + AC300_EPHY_LNK_LED_IO_ENABLE | \ + AC300_EPHY_SPD_LED_IO_ENABLE | \ + AC300_EPHY_DPX_LED_IO_ENABLE) static u16 ac300_ephy_ctl_config(const struct ac300_ephy_ctl *priv) {
@@ -131,7 +138,8 @@ static u16 ac300_ephy_ctl_config(const structac300_ephy_ctl *priv) return priv->ephy_config | + AC300_EPHY_LED_POL_ACTIVE_LOW | (priv->interface == PHY_INTERFACE_MODE_RMII ? AC300_EPHY_RMII_SEL : 0); } -- Alastair D'Silva