Hi Florian, On Wed, Jun 27, 2018 at 10:54:24AM -0700, Florian Fainelli wrote: > On 06/26/2018 05:06 PM, Paul Burton wrote: > > When using a PHY connected via RGMII, as the pch_gbe driver presumes is > > the case, the RX clock is provided by the PHY to the MAC. Various PHYs, > > including both the AR8031 used by the Minnowboard & the RTL8211E used by > > the MIPS Boston development board, will stop generating the RX clock > > when the ethernet link is down (eg. the ethernet cable is unplugged). > > > > Various pieces of functionality in the EG20T MAC, ranging from basics > > like completing a MAC reset to programming MAC addresses, rely upon the > > RX clock being provided. When the clock is not provided these pieces of > > functionality simply never complete, and the busy bits that indicate > > they're in progress remain set indefinitely. > > > > The pch_gbe driver currently requires that the RX clock is always > > provided, and attempts to enforce this by disabling the hibernation > > feature of the AR8031 PHY to keep it generating the RX clock. This patch > > moves us away from this model by only configuring the MAC when the PHY > > indicates that the ethernet link is up. When the link is up we should be > > able to safely expect that the RX clock is being provided, and therefore > > safely reset & configure the MAC. > > What we ended up doing in the bcmgenet driver is loop back the RX and TX > clocks such that we always have a clock that we can use to perform any > MAC operation, including reset. > > Is this an option here?
That sounds like a nice solution, but I don't see a way to do it in the EG20T datasheet[1]. > You might also want to split the allocation from the actual > initialization if this is not done already. Some of the buffer allocation is still happening in pch_gbe_up() rather than when the link actually comes up, but there is more that could probably be moved. Thanks, Paul [1] https://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/platform-controller-hub-eg20t-datasheet.html