Message-ID: <DB8PR04MB6795BCB93919DF684CA8DA79E6909@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date:   Thu, 11 Mar 2021 12:04:28 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Florian Fainelli <f.fainelli@...il.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


> -----Original Message-----
> From: Florian Fainelli <f.fainelli@...il.com>
> Sent: 2021年3月9日 1:57
> To: Joakim Zhang <qiangqing.zhang@....com>; Jakub Kicinski
> <kuba@...nel.org>; Andrew Lunn <andrew@...n.ch>
> Cc: 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fnetdev%2Fnet%2Fc%2F9a7b3950c7e1&amp;data=04%7C01%7Cqian
> gqing.zhang%40nxp.com%7Cb7e83671b0184471020708d8e25b8ca6%7C686ea
> 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637508230113442096%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LPY4fazuJFAOanncuGll1jGK8W
> bxiR2iZ5KfuuaAk98%3D&amp;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

Powered by blists - more mailing lists