During mass manufacturing, we noticed the mmc_rx_crc_error counter, as reported by "ethtool -S eth0 | grep mmc_rx_crc_error" to increase above zero during nuttcp speedtests.
Cycling through the rx_delay range on two boards shows that there is a large "good" region from 0x11 to 0x35 (see below for details).
This commit increases rx_delay to 0x11, which is the smallest possible change that fixes the issue we are seeing on the KSZ9031 PHY. This also matches what most other rk3399 boards do.
Tests for Puma PCBA S/N TT0069903:
rx_delay mmc_rx_crc_error -------- ---------------- 0x09 (dhcp broken) 0x10 897 0x11 0 0x20 0 0x30 0 0x35 0 0x3a 745 0x3b 11375 0x3c 36680 0x40 (dhcp broken) 0x7f (dhcp broken)
Tests for Puma PCBA S/N TT0157733:
rx_delay mmc_rx_crc_error -------- ---------------- 0x10 59 0x11 0 0x35 0
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable@vger.kernel.org Reviewed-by: Quentin Schulz quentin.schulz@cherry.de Signed-off-by: Jakob Unterwurzacher jakob.unterwurzacher@cherry.de --- v2: cc stable, add "Fixes:", add omitted "there" to commit msg, add Reviewed-by.
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index 9efcdce0f593..13d0c511046b 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -181,7 +181,7 @@ &gmac { snps,reset-active-low; snps,reset-delays-us = <0 10000 50000>; tx_delay = <0x10>; - rx_delay = <0x10>; + rx_delay = <0x11>; status = "okay"; };