Re: [linux-sunxi] [PATCH 02/10] ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY

[Ard Biesheuvel]

On Sat, 24 Oct 2020 at 20:40, Icenowy Zheng <icenowy@xxxxxxx> wrote:
>
>
>
> 于 2020年10月25日 GMT+08:00 上午2:30:35, "Jernej Škrabec" <jernej.skrabec@xxxxxxxx> 写到:
> >Dne sobota, 24. oktober 2020 ob 19:51:06 CEST je Icenowy Zheng
> >napisal(a):
> >> 在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：
> >>
> >> > From: Chen-Yu Tsai <wens@xxxxxxxx>
> >> >
> >> > The Ethernet PHY on the A31 Hummingbird has the RX and TX delays
> >> > enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins.
> >> >
> >> > Fix the phy-mode description to correct reflect this so that the
> >> > implementation doesn't reconfigure the delays incorrectly. This
> >> > happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
> >> > rx/tx delay config").
> >>
> >> Personally I think they should revert this commit, and consider other
> >> solution.
> >>
> >> This commit breaks everything.
> >>
> >
> >Previously broken driver allowed inproper DT to work, so you have to
> >fix
> >everything eventually.
>
> There is no "improper DT" if it's already shipped, DT should suffer driver
> change, not changed to match driver.
>
> I think at least Fedora tends to ship a DT with a system image that will
> not get updated when kernel gets updated.
>

This same issue is under discussion in other places as well:

The following commit from v5.2

f81dadbcf7fd ("net: phy: realtek: Add rtl8211e rx/tx delays config")

added handling of the TX/RX delay controls on the PHY, but did so
incorrectly, and therefore had no effect on any of these systems.

Commit

bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")

fixed TX/RX delay handling in v5.9, and now, incorrect phy-mode
settings in DT means losing Ethernet connectivity. This patch has been
backported to -stable, even though it is not clear at all that the
patch fixes any regressions, it only fixes some broken code that did
not turn out to be active in the first place.


The result of this is that affected systems in the field using v5.4 or
v5.8 stable kernels will lose their Ethernet connectivity once they
upgrade to a newer release of the same v5.x tree that they shipped
with. We may have ways to work around this more cleanly, but in the
meantime, the stable backports of bbc4d71d6354 should simply be
reverted (IMHO)