[PATCH net-next v3 0/3] net: stmmac: add Allwinner H616 EMAC1 support
Alastair D'Silva
alastair at d-silva.org
Thu Sep 17 21:17:34 PDT 2026
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 <james.hilliard1 at gmail.com>
> ---
> 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 at 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 at 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 <james.hilliard1 at gmail.com>
>
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/
root at 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 at 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 at 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 at 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 struct
ac300_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
More information about the linux-arm-kernel
mailing list