Re: [REGRESSION] stmmac: Random DMA reset failure on RK3399 since v6.18

[Jensen Huang]

On Tue, May 5, 2026 at 4:26 PM Thorsten Leemhuis
<regressions@xxxxxxxxxxxxx> wrote:
>
> [Jumping in here, as there are no replies yet]
>
> BTW, Russel, just in case you missed this: looks like this regressions
> caused by a change of yours.
>
> On 4/29/26 14:53, Jensen Huang wrote:
> >
> > I'm reporting a regression on RK3399 (stmmac) observed in v6.18.24.
> > When a network cable is connected during boot, the DMA reset
> > occasionally fails with the error message: "Failed to reset the dma".
> >
> > This appears to be a timing issue related to the EEE RX clock-stop
> > logic. Based on my investigation with the RTL8211E PHY, I monitored
> > the PHY register PS1R (MMD device 3, address 0x01) and observed a
> > value of 0x0f40. This indicates that the PHY is in LPI mode and the RX
> > clock may have already stopped.
> >
> > While commit dd557266cf5f ("net: stmmac: block PHY RXC clock-stop")
>
> Just wondering: have you tried if mainline (e.g. 7.1-rc1) is still
> affected? This is something that is always a good advisable (some people
> would call it required). In this case even more, as it since a while
> contains a fix for the change you mentioned, that wasn't backported:
> c171e679ee66d7 ("net: stmmac: Disable EEE RX clock stop when VLAN is
> enabled"). But this is not my area of expertise (and in different area
> of the code), so that fix might be unrelated to your issue.

Thanks for the pointer.
As you suggested, I have tested the mainline and confirmed that the
issue is not present in v7.1-rc2, nor as early as v6.19-rc1. However,
I verified that the issue persists in the latest stable v6.18.26.
I performed a git bisect and the result pointed exactly to the commit
you mentioned: c171e679ee66d7 ("net: stmmac: Disable EEE RX clock stop
when VLAN is enabled").
Additionally, I tested the case where CONFIG_VLAN_8021Q is not set,
and the DMA reset issue occurs again.


Best regards,
Jensen Huang

>
> Ciao, Thorsten
>
> > ensures the clock is running before the DMA reset, my tests suggest
> > that the phylink_rx_clk_stop_block() call might not provide a
> > sufficiently stable RX clock in time for the immediate DMA reset that
> > follows.
> >
> > Since stmmac already sets mac_requires_rxc = true, I modified
> > phylink_bringup_phy() to honor this flag. This avoids toggling the
> > PHY's clk_stop_enable during the initialization sequence, ensuring the
> > RX clock remains active and stable throughout.
> > With the change below, I achieved 200/200 successful reboots with the
> > cable connected (previously ~50% failure rate).
> >
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -2171,7 +2171,7 @@ static int phylink_bringup_phy(struct phylink
> > *pl, struct phy_device *phy,
> >      /* Allow the MAC to stop its clock if the PHY has the capability */
> >      pl->mac_tx_clk_stop = phy_eee_tx_clock_stop_capable(phy) > 0;
> >
> > -    if (pl->mac_supports_eee_ops) {
> > +    if (pl->mac_supports_eee_ops && !pl->config->mac_requires_rxc) {
> >          /* Explicitly configure whether the PHY is allowed to stop it's
> >           * receive clock.
> >           */
> >
> > Any feedback/testing on this would be appreciated.
> >
> > Best regards,
> > Jensen Huang
> >
>