From: Alastair D'Silva <alastair@d-silva.org>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>,
James Hilliard <james.hilliard1@gmail.com>,
wens@kernel.org
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>
Subject: Re: [PATCH net-next 0/4] net: Add Allwinner H616/H618 EMAC1 and AC300 EPHY support
Date: Wed, 16 Sep 2026 18:02:08 +1000 [thread overview]
Message-ID: <a5fed5614eb09f958772fae636e748069851e059.camel@d-silva.org> (raw)
In-Reply-To: <3196ccec-7cf3-434b-b7bb-dec64fe29583@bootlin.com>
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
prev parent reply other threads:[~2026-09-16 8:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 4:41 [PATCH net-next 0/4] net: Add Allwinner H616/H618 EMAC1 and AC300 EPHY support Alastair D'Silva
2026-09-16 4:41 ` [PATCH net-next 1/4] dt-bindings: net: phy: Add Allwinner AC300 EPHY binding Alastair D'Silva
2026-09-16 14:49 ` Andrew Lunn
2026-09-16 15:22 ` Rob Herring (Arm)
2026-09-16 4:41 ` [PATCH net-next 2/4] net: phy: Add Allwinner AC300 EPHY driver Alastair D'Silva
2026-09-16 15:05 ` Andrew Lunn
2026-09-16 4:41 ` [PATCH net-next 3/4] dt-bindings: net: allwinner,sun8i-a83t-emac: Add Allwinner H616 EMAC1 and syscon index Alastair D'Silva
2026-09-16 15:22 ` Rob Herring (Arm)
2026-09-16 4:41 ` [PATCH net-next 4/4] net: stmmac: dwmac-sun8i: Add Allwinner H616 EMAC clock index and internal PHY support Alastair D'Silva
2026-09-16 6:24 ` Maxime Chevallier
2026-09-16 6:29 ` James Hilliard
2026-09-16 6:45 ` Alastair D'Silva
2026-09-16 6:47 ` Andre Przywara
2026-09-16 4:56 ` [PATCH net-next 0/4] net: Add Allwinner H616/H618 EMAC1 and AC300 EPHY support Chen-Yu Tsai
2026-09-16 5:12 ` James Hilliard
2026-09-16 6:49 ` Alastair D'Silva
2026-09-16 7:06 ` Maxime Chevallier
2026-09-16 8:02 ` Alastair D'Silva [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a5fed5614eb09f958772fae636e748069851e059.camel@d-silva.org \
--to=alastair@d-silva.org \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=james.hilliard1@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=samuel@sholland.org \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox