On Sun, 25 Oct 2020 at 15:29, Andrew Lunn <and...@lunn.ch> wrote: > > On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote: > > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn <and...@lunn.ch> wrote: > > > > > > > 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. >
Would you suggest that these DTs remove the phy-mode instead? As I don't see anyone proposing that. > 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. > That sounds reasonable, given how many different platforms seem to be affected, and production ones may be running stable distro kernels, and not expecting their Ethernet to fail without warning.
