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

[Diederik de Haas]

On Monday, 4 March 2024 16:59:38 CET Andrew Lunn wrote:
> On Mon, Mar 04, 2024 at 04:32:03PM +0100, Diederik de Haas wrote:
> > 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?
> 
> If you don't have a specific Linux PHY driver, you are at the mercies
> of how the bootloader, or strapping set up the PHY. So it is always
> best to use the correct PHY driver. 

This part is a bit over my head (that's ok, no need to explain it).

> The Linux PHY driver should assume
> nothing and setup the hardware from scratch, removing anything odd the
> bootloader did. However, the fall back generic PHY driver has no chip
> specific knowledge, so it cannot undo whatever the bootloader did.
> 
> So, in an ideal world, we don't care about what the bootloader did,
> just use the correct MAC and PHY driver and it should work. And if it
> does not work, it is a Linux bug, which needs to be found and fixed.

I agree.

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

That was because it's actually a bug report (wrt Quartz64 A and B), but 
especially your remark made all the pieces I found earlier fall into place.
Therefor I 'abused' this thread/patch to report it.

I'm happy to test patches, but I lack the knowledge to come up with one 
myself.

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/52ddb0b4/attachment.sig>