[PATCH net-next 0/4] net: Add Allwinner H616/H618 EMAC1 and AC300 EPHY support

Alastair D'Silva alastair at d-silva.org
Wed Sep 16 01:02:08 PDT 2026


On Wed, 2026-09-16 at 09:06 +0200, Maxime Chevallier wrote:
> Hi,
> On 9/16/26 08:49, Alastair D'Silva wrote:
> 
> > There is one subtle timing issue worth highlighting from our
> > Armbian
> > testing on the Mellow Fly-C5 (H618):
> > 
> > In James's dwmac patch, setting soc_has_internal_phy = false causes
> > sun8i_dwmac_probe() to fall through to sun8i_dwmac_reset(priv). The
> > Synopsys EMAC DMA soft reset (EMAC_BASIC_CTL1 bit 0) requires a
> > running
> > RMII clock from the PHY to clear.
> > 
> > While this reset succeeds when the PHY driver is built-in and
> > probes
> > synchronously, if CONFIG_XPOWERS_ACX00_PHY is built as a module
> > (=m)
> > or if the PHY probe defers (-EPROBE_DEFER on
> > regulator/clock/nvmem),
> > the PHY is unpowered and not clocking when sun8i_dwmac_probe()
> > runs.
> > 
> > This causes sun8i_dwmac_reset() to time out after 100ms ("EMAC
> > reset
> > timeout"), failing MAC driver probe. In our testing, deferring the
> > MAC
> > reset until sun8i_dwmac_init() (which runs upon ndo_open after
> > phylink
> > has attached and the PHY is active) avoided this probe failure.
> 
> I'm OK with going with James' version, however this seems like a
> valid
> point that needs to be figured out.
> 
> James, can you add Alastair in CC of your next iterations, and
> Alastair
> it would be great if you could give James's patches a test when he
> submits them :)
> 
> There's more stuff in the dwmac part for Alastair's version, some
> -EPROBEFER handling for clocks, the reset thing as well as the MUX
> part, for which use-cases is all of that required ?
> 
> If that's something that needs to land with proper EMAC1 support,
> maybe
> this could be split out from Alastair's work (in individual patches
> please), and integrated in James's series ?
> 
> Maxime

Thanks Maxime. Here is the breakdown of why those pieces were in my
earlier patch and how they relate to James's series:

1. MDIO MUX & H3_EPHY_SELECT:
   These are NOT needed for James's series.
   My initial test tree was using the legacy
   "allwinner,sun8i-h3-mdio-mux" node inherited from older
   vendor/Armbian DTs. That mux driver attempts to toggle
   H3_EPHY_SELECT (bit 0 of SYSCON), which on H616 register 0x34 is
   actually SYSCON_EPIT (interface type), so I had to mask it out.
   With James's series, there is no fake mdio-mux node (direct MDIO bus
   with the ethernet-phy-package), which is much cleaner and completely
   bypasses all H3 mux code.

2. -EPROBE_DEFER handling in get_ephy_nodes():
   Also NOT needed for H616 EMAC1.
   get_ephy_nodes() is only called when soc_has_internal_phy = true.
   In James's series, all PHY clocks, regulators, and NVMEM cells are
   managed inside the PHY package driver
   (drivers/net/phy/xpowers/ac300.c), where -EPROBE_DEFER is already
   handled cleanly via dev_err_probe().
   (The get_ephy_nodes() fix is only relevant as an independent 
   cleanup for legacy H3/V3s platforms).

3. MAC Soft Reset timing (The one piece that IS needed):
   This is the one issue that affects James's series.
   Because emac_variant_h616_emac1 sets soc_has_internal_phy = false,
   sun8i_dwmac_probe() falls through to line 1221:
       ret = sun8i_dwmac_reset(priv);

   The Allwinner EMAC DMA soft reset (EMAC_BASIC_CTL1 bit 0) requires
   the RMII clock from the PHY to toggle in order to complete.
   If CONFIG_XPOWERS_ACX00_PHY is built as a module (=m), or if any of
   the AC300 package resources defer probe, the PHY is unpowered and
   not clocking during sun8i_dwmac_probe(). sun8i_dwmac_reset() will
   time out after 100ms ("EMAC reset timeout"), aborting the MAC probe
   completely.
   For EMAC1, skipping sun8i_dwmac_reset() during probe and letting it
   run in sun8i_dwmac_init() (which runs upon ndo_open after phylink
   has connected and the PHY is clocked) avoids this probe failure.

James, I'm happy to test your next revision on physical Mellow Fly-C5
(H618) hardware as both a builtin driver, and a module.

-- 
Alastair D'Silva
0493 18 5566



More information about the linux-arm-kernel mailing list