[PATCH] arm64: dts: ti: k3-am625-beagleplay: Use the builtin mdio bus

[Sjoerd Simons]

On Fri, 2024-01-12 at 08:25 -0600, Nishanth Menon wrote:
> On 15:20-20240112, Sjoerd Simons wrote:
> > On Fri, 2024-01-12 at 07:50 -0600, Nishanth Menon wrote:
> > > On 13:44-20240112, Sjoerd Simons wrote:
> > > > The beagleplay dts was using a bit-bang gpio mdio bus as a
> > > > work-
> > > > around
> > > > for errata i2329. However since commit d04807b80691 ("net:
> > > > ethernet: ti:
> > > > davinci_mdio: Add workaround for errata i2329") the mdio driver
> > > > itself
> > > > already takes care of this errata for effected silicon, which
> > > > landed
> > > > well before the beagleplay dts. So i suspect the reason for the
> > > > workaround in upstream was simply due to copying the vendor
> > > > dts.
> > > > 
> > > > Switch the dts to the ti,cpsw-mdio instead so it described the
> > > > actual
> > > > hardware and is consistent with other AM625 based boards
> > > > 
> > > > Signed-off-by: Sjoerd Simons <sjoerd at collabora.com>
> > > > 
> > > > ---
> > > 
> > > We have had issues with the ethernet integration previously (also
> > > why
> > > ethernet in u-boot is not yet functional on beagleplay[1]).
> > > 
> > > https://openbeagle.org/beagleplay/beagleplay/-/issues/101
> > > 
> > > we should probably do a 1000 boot nfs test or something to ensure
> > > this
> > > doesn't introduce regressions (I recollect mdio wasn't stable on
> > > beagleplay) and switching to bitbang driver stopped all
> > > complains.
> > 
> > I can do a longer test with that over the weekend sure; For
> > reference
> > I'm seeing issues in u-boot as well on initial probe with these
> > changes, but i've not seen the same on the linux side.
> > 
> > Do you remember with what kernel versions users saw the mdio
> > instabilities? I wonder if that was a version with the commit
> > mentioned
> > that includes the errata fix for the mdio driver.
> > 
> 
> we were on TI 5.10 kernel (the image that went into production) and
> it
> did have errata fix (I am not sure if it is similar or same as what
> finally went into upstream now).. I have started an automated
> multiple
> boot test on my end as well..
> 
> The signature as I recollect was spurious link Down and Up logs
> (though the cable is not physically disconnected).. been a bit of
> time.. so my memory on exact signature might be vague.

For reference over the weekend our test infra did over 1600 boots with
an NFS root fs (see [0] for an example job) without a single boot
failure. So with the upstream kernel this seems pretty solid.


0: https://staging.lava.collabora.dev/scheduler/job/572063


-- 
Sjoerd Simons
Collabora Ltd.