[PATCH] arm64: dts: rockchip: qnap-ts433: Simplify network PHY connection

[Diederik de Haas]

On Monday, 4 March 2024 14:09:15 CET Andrew Lunn wrote:
> > > Andrew already pointed out when I posted the patch introducing the gmac0
> > > node that rgmii-id would be the preferred way to setup things. Back
> > > then this didn't happen because this change broke reception of network
> > > packets. However this only happend because I didn't have the right phy
> > > driver loaded.
> > 
> > It could be that the PHY is strapped to not use its internal RX delay.
> > And the PHY has some weird default TX delay, so having the driver
> > put some sensible values in is probably better.
> 
> It could also be the bootloader putting odd values into the PHY.
> 
> Anyway, it will work better with the correct PHY, and enable WoL
> support.

Not sure if this is the right place or way, but here we go...

A few days ago on #debian-kernel at OFTC:
[28.02 16:35] <ukleinek> u-boot should be out of the game
[28.02 16:36] <diederik> I'm not so sure anymore. On Quartz64 Model A and B 
(rk3566) I had massive packet loss and tracked it down to a change in u-boot
[28.02 16:37] <ukleinek> diederik: sounds like the Linux network driver on 
that machine could do something better
[28.02 16:38] <diederik> yeah, probably

I reported this about a month ago to Jonas Karlman as I bisected the problem 
to a change in u-boot:

> diederik at bagend:~/dev/u-boot/u-boot$ git bisect bad
> 25f56459aebced8e4bb7d01061dcb1b765b197e2 is the first bad commit
> commit 25f56459aebced8e4bb7d01061dcb1b765b197e2
> Author: Jonas Karlman <jonas at kwiboo.se>
> Date:   Sun Oct 1 19:17:21 2023 +0000
> 
>     configs: rockchip: Enable ethernet driver on RK356x boards
>     
>     Enable DWC_ETH_QOS_ROCKCHIP and related PHY driver on RK356x boards that
>     have an enabled gmac node.

I just checked and both Quartz64 Model A and B have `phy-mode = "rgmii";` and 
set `tx_delay` and `rx_delay` to some (other) values.
Without knowing nor understanding the details, this seem very much related?

Cheers,
  Diederik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240304/bd90f931/attachment.sig>