lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d636daa-b25a-d0f1-dc95-b021cb0f53eb@gmail.com>
Date:   Fri, 12 Mar 2021 10:33:06 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Joakim Zhang <qiangqing.zhang@....com>,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: stmmac driver timeout issue

On 3/11/21 4:04 AM, Joakim Zhang wrote:
> 
>> -----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.

Adding Heiner and Russell as well. Usually you do not want, or rather
cannot know whether auto-negotiation will ever succeed, so waiting for
it could essentially hog your system for some fairly indefinite amount
of time.

With respect to your Realtek PHY is there no way you can force it to
output the 125MHz RX clock towards the MAC while you perform the MAC
initialization?
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ