[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49fedeb2-b25b-10d0-575f-f9808a537124@gmail.com>
Date: Mon, 8 Mar 2021 09:56:46 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Joakim Zhang <qiangqing.zhang@....com>,
Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: stmmac driver timeout issue
On 3/8/21 4:45 AM, Joakim Zhang wrote:
>
> Hi Florian, Andrew,
>
> Thanks for your help, after debug, It seems related to PHY(RTL8211FDI). It stop output RXC clock for dozens to hundreds milliseconds during auto-negotiation, and there is no such issue with AR8031.
> When do ifup/ifdown test or system suspend/resume test, it will suspend then resume phy which do power down and then change to normal operation.(switch from power to normal operation)
>
> There is a note in RTL8211FDI datasheet:
> Note 2: When the RTL8211F(I)/RTL8211FD(I) is switched from power to normal operation, a software reset and restart auto-negotiation is performed, even if bits Reset(0.15) and Restart_AN(0.9) are not set by the users.
>
> Form above note, it will trigger auto-negotiation when do ifup/ifdown test or system suspend/resume, so we will meet RXC clock is stop issue on RTL8211FDI. My question is that, Is this a normal behavior, all PHYs will perform this behavior? And Linux PHY frame work can handle this case, there is no config_init after resume, will the config be reset?
I do not have experience with Realtek PHYs however what you describe
does not sound completely far off from what Broadcom PHYs would do when
auto-power down is enabled and when the link is dropped either because
the PHY was powered down or auto-negotiation was restarted which then
leads to the RXC/TXC clocks being disabled.
For RGMII that connects to an actual PHY you can probably use the same
technique that Doug had implemented for GENET whereby you put it in
isolate mode and it maintains its RXC while you do the reset. The
problem is that this really only work for an RGMII connection and a PHY,
if you connect to a MAC you could create contention on the pins. I am
afraid there is no fool proof situation but maybe you can find a way to
configure the STMMAC so as to route another internal clock that it
generates as a valid RXC just for the time you need it?
With respect to your original problem, looks like it may be fixed with:
https://git.kernel.org/netdev/net/c/9a7b3950c7e1
or maybe this only works on the specific Intel platform?
--
Florian
Powered by blists - more mailing lists