Re: realtek PHY commit bbc4d71d63549 causes regression
From: Andrew Lunn <andrew@lunn.ch>
Date: 2020-10-25 14:29:03
On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
On Sun, 18 Oct 2020 at 17:45, Andrew Lunn [off-list ref] wrote:quoted
quoted
However, that leaves the question why bbc4d71d63549bcd was backported, although I understand why the discussion is a bit trickier there. But if it did not fix a regression, only broken code that never worked in the first place, I am not convinced it belongs in -stable.Please ask Serge Semin what platform he tested on. I kind of expect it worked for him, in some limited way, enough that it passed his testing.I'll make a note here that a rather large number of platforms got broken by the same fix for the Realtek PHY driver: https://lore.kernel.org/lkml/?q=bbc4d71d6354 I seriously doubt whether disabling TX/RX delay when it is enabled by h/w straps is the right thing to do here.
The device tree is explicitly asking for rgmii. If it wanted the
hardware left alone, it should of used PHY_INTERFACE_MODE_NA.
But we might be able to compromise for a cycle or two. As far as i
understand the hardware, we can read the strapping. If we find the
strapping resisters are present, but rgmii is in DT, print a warning
that the device tree needs upgrading, and ignore the DT mode. We can
add this to stable, but not net-next.
Andrew