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

Greg, Sasha, could you please cherry-pick c171e679ee66d7 ("net: stmmac:
Disable EEE RX clock stop when VLAN is enabled") [v6.19-rc1] to 6.18.y?
It fixes a regression for Jensen Huang (for details see below; it was
later confirmed that c171e679ee66d7 really fixes this) caused by
dd557266cf5fb0 ("net: stmmac: block PHY RXC clock-stop") [v6.15-rc1]. tia!

Ciao, Thorsten

On 5/7/26 15:13, Thorsten Leemhuis wrote:
> [+Ovidiu Panait]
> On 5/7/26 14:49, Jensen Huang wrote:
>> On Tue, May 5, 2026 at 4:26 PM Thorsten Leemhuis
>> <[email protected]> wrote:
>>> 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").
> 
> Great! Could you please cherry-pick c171e679ee66d7 to 6.18.y and see if
> that fixes things? It sounds like it should.
> 
> @Ovidiu Panait: c171e679ee66d7 is a commit of yours. If Jensen confirms
> that cherry-picking fixed the problem, I'd say we ask Greg to pick it up
> for 6.18.y -- unless you see any reasons why that might be a bad idea.
> 
>> Additionally, I tested the case where CONFIG_VLAN_8021Q is not set,
>> and the DMA reset issue occurs again.
> 
> I'd say that is likely best discussed in a new thread you might want to
> start. Also wondering if it was like that earlier. Or iow: if that is a
> regression or not.
> 
> 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
>>>>
>>>
>