> -----Original Message----- > From: Florian Fainelli <f.faine...@gmail.com> > Sent: 2021年3月9日 1:57 > To: Joakim Zhang <qiangqing.zh...@nxp.com>; Jakub Kicinski > <k...@kernel.org>; Andrew Lunn <and...@lunn.ch> > Cc: netdev@vger.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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > el.org%2Fnetdev%2Fnet%2Fc%2F9a7b3950c7e1&data=04%7C01%7Cqian > gqing.zhang%40nxp.com%7Cb7e83671b0184471020708d8e25b8ca6%7C686ea > 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637508230113442096%7CUnk > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LPY4fazuJFAOanncuGll1jGK8W > bxiR2iZ5KfuuaAk98%3D&reserved=0 > > or maybe this only works on the specific Intel platform?
Thanks Florian, I also noticed that patch, but that should work for driver remove. The key is RXC not stable when auto-nego at my side. I have a question about PHY framework, please point me if something I misunderstanding. There are many scenarios from PHY framework would trigger auto-nego, such as switch from power down to normal operation, but it never polling the ack of auto-nego (phy_poll_aneg_done), is there any special reasons? Is it possible and reasonable for MAC controller driver to poll this ack, if yes, at least we have a stable RXC at that time. Best Regards, Joakim Zhang > -- > Florian
