From: Pedro Santos <hartmnn.p@gmail.com>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Andre Przywara <andre.przywara@arm.com>,
Corentin Labbe <clabbe.montjoie@gmail.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, Pedro Santos <hartmnn.p@gmail.com>
Subject: [PATCH net] net: stmmac: dwmac-sun8i: reset the EMAC when opening, not when probing
Date: Sat, 22 Aug 2026 01:56:41 -0300 [thread overview]
Message-ID: <20260822045641.19282-1-hartmnn.p@gmail.com> (raw)
sun8i_dwmac_reset() asserts EMAC_BASIC_CTL1.SOFT_RST and polls for the
hardware to clear it. That bit only clears once the MAC has a running
receive clock, which on external-PHY boards is driven by the PHY.
Bringing the interface down powers the PHY down: phy_detach() calls
phy_suspend(), which for a PHY without wake-on-LAN ends in BMCR_PDOWN.
Boards that wire no reset line to their PHY, and share its supply with
other always-on consumers, have nothing that undoes that. On the Orange
Pi Zero 3 the Motorcomm YT8531 reset is, in the words of the board's
upstream author, "hardwired via a simple RC circuit, so there is no
GPIO", and phy-supply points at a regulator-always-on rail shared with
four GPIO banks and the SD card.
So after a warm reboot the PHY comes back still powered down. Probe
asserts SOFT_RST, no receive clock arrives, and the reset never
completes. Read off an affected board at boot, before anything touched
the PHY: BMCR 0x1800 (PDOWN set) and EMAC_BASIC_CTL1 0x08000001, still
set after polling for ten seconds -- so raising the 100 ms timeout does
not help. Probe fails with -ETIMEDOUT and the interface never appears.
That the interface teardown is what does it can be shown directly. A
reboot via sysrq-b, which skips both the ifdown and device_shutdown(),
comes up with PDOWN clear and resets fine; taking the interface down
first and then using sysrq-b -- so the driver's own shutdown path still
never runs -- reproduces the failure.
The driver already has the right place for the reset.
sun8i_dwmac_dma_reset() is registered as stmmac_dma_ops->reset and is
documented as "reset the EMAC", but only zeroes a few registers. stmmac
calls it from stmmac_init_dma_engine(), under stmmac_hw_setup(), whose
only two callers are __stmmac_open() and stmmac_resume() -- both of which
run after stmmac_init_phy() has attached and resumed the PHY. Doing the
soft reset there means the receive clock is running by construction, for
every PHY, whether or not a PHY driver is bound, without the MAC driver
reaching into phylib.
sun8i is the only stmmac variant that soft-resets at probe rather than in
the reset hook; this brings it into line with the others.
sun8i_dwmac_reset() stays for the mdio-mux switch callback, which needs a
reset after changing the syscon and cannot use the hook.
Tested on an Orange Pi Zero 3 (H618, YT8531, rgmii-rxid). Five warm
reboots: no EMAC reset timeout, interface up at 1Gbps each time. One cold
boot with power physically cycled, to cover the path this moves for
boards that never hit the bug: same result. 20000 and 5000 1472-byte
frames respectively, no loss, every MAC error counter at zero.
Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
Signed-off-by: Pedro Santos <hartmnn.p@gmail.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 49 ++++++++++++-------
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 48c52eb..748ebab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -272,8 +272,34 @@ static const struct emac_variant emac_variant_h6 = {
/* sun8i_dwmac_dma_reset() - reset the EMAC
* Called from stmmac via stmmac_dma_ops->reset
*/
+static int sun8i_dwmac_soft_reset(void __iomem *ioaddr)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_BASIC_CTL1);
+ writel(v | 0x01, ioaddr + EMAC_BASIC_CTL1);
+
+ /* The timeout was previously set to 10ms, but some board (OrangePI0)
+ * need more if no cable plugged. 100ms seems OK
+ */
+ return readl_poll_timeout(ioaddr + EMAC_BASIC_CTL1, v,
+ !(v & 0x01), 100, 100000);
+}
+
static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
{
+ int err;
+
+ /* The MAC soft reset only completes once the PHY is driving the RX
+ * clock. Doing it here rather than at probe means phylib has already
+ * attached and resumed the PHY, so the clock is running by
+ * construction -- including after a warm reboot that left the PHY
+ * powered down.
+ */
+ err = sun8i_dwmac_soft_reset(ioaddr);
+ if (err)
+ return err;
+
writel(0, ioaddr + EMAC_RX_CTL1);
writel(0, ioaddr + EMAC_TX_CTL1);
writel(0, ioaddr + EMAC_RX_FRM_FLT);
@@ -740,23 +766,12 @@ static void sun8i_dwmac_flow_ctrl(struct mac_device_info *hw,
static int sun8i_dwmac_reset(struct stmmac_priv *priv)
{
- u32 v;
- int err;
-
- v = readl(priv->ioaddr + EMAC_BASIC_CTL1);
- writel(v | 0x01, priv->ioaddr + EMAC_BASIC_CTL1);
+ int err = sun8i_dwmac_soft_reset(priv->ioaddr);
- /* The timeout was previously set to 10ms, but some board (OrangePI0)
- * need more if no cable plugged. 100ms seems OK
- */
- err = readl_poll_timeout(priv->ioaddr + EMAC_BASIC_CTL1, v,
- !(v & 0x01), 100, 100000);
-
- if (err) {
+ if (err)
dev_err(priv->device, "EMAC reset timeout\n");
- return err;
- }
- return 0;
+
+ return err;
}
/* Search in mdio-mux node for internal PHY node and get its clk/reset */
@@ -1217,10 +1232,6 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Failed to register mux\n");
goto dwmac_mux;
}
- } else {
- ret = sun8i_dwmac_reset(priv);
- if (ret)
- goto dwmac_remove;
}
pm_runtime_put(&pdev->dev);
--
2.50.1 (Apple Git-155)
next reply other threads:[~2026-08-22 4:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 4:56 Pedro Santos [this message]
2026-08-25 12:41 ` [PATCH net] net: stmmac: dwmac-sun8i: reset the EMAC when opening, not when probing Paolo Abeni
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=20260822045641.19282-1-hartmnn.p@gmail.com \
--to=hartmnn.p@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andre.przywara@arm.com \
--cc=andrew+netdev@lunn.ch \
--cc=clabbe.montjoie@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jernej.skrabec@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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