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

On Sat, 24 Oct 2020 at 20:40, Icenowy Zheng [off-list ref] wrote:

于 2020年10月25日 GMT+08:00 上午2:30:35, "Jernej Škrabec" [off-list ref] 写到:

quoted

Dne sobota, 24. oktober 2020 ob 19:51:06 CEST je Icenowy Zheng
napisal(a):

quoted

在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：

quoted

From: Chen-Yu Tsai <redacted>

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)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel