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@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@bagend:~/dev/u-boot/u-boot$ git bisect bad
> > 25f56459aebced8e4bb7d01061dcb1b765b197e2 is the first bad commit
> > commit 25f56459aebced8e4bb7d01061dcb1b765b197e2
> > Author: Jonas Karlman <jonas@xxxxxxxxx>
> > 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. 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.
Andrew
