[net-next,v3,0/3] net: stmmac: add Allwinner H616 EMAC1 support

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@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@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 <james.hilliard1@gmail.com>
  

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@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@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 <james.hilliard1@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@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 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);
 }
  

Hi Alastair,


> 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/
> 
Thanks a lot for testing, this is great :)

Can you add you Tested-by tag ?

Thanks,

Maxime
  

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@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@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 <james.hilliard1@gmail.com>
> 

Tested-by: Alastair D'Silva <alastair@d-silva.org>
Reviewed-by: Alastair D'Silva <alastair@d-silva.org>

As a follow-up (non blocking), I would add the LED control registers I
mentioned at the bottom of my test results.