Re: [PATCH 0/2] net: stmmac: allow sharing MDIO lines

Andrew Lunn
2023-08-08T18:07:47Z

> > On Tue, Aug 08, 2023 at 10:13:09AM +0200, Bartosz Golaszewski wrote:
> > > Ok so upon some further investigation, the actual culprit is in stmmac
> > > platform code - it always tries to register an MDIO bus - independent
> > > of whether there is an actual mdio child node - unless the MAC is
> > > marked explicitly as having a fixed-link.
> > >
> > > When I fixed that, MAC1's probe is correctly deferred until MAC0 has
> > > created the MDIO bus.
> > >
> > > Even so, isn't it useful to actually reference the shared MDIO bus in some way?
> > >
> > > If the schematics look something like this:
> > >
> > > -------- -------
> > > | MAC0 |--MDIO-----| PHY |
> > > -------- | | -------
> > > | |
> > > -------- | | -------
> > > | MAC1 |-- ----| PHY |
> > > -------- -------
> > >
> > > Then it would make sense to model it on the device tree?
> >
> > So I think what you're saying is that MAC0 and MAC1's have MDIO bus
> > masters, and the hardware designer decided to tie both together to
> > a single set of clock and data lines, which then go to two PHYs.
>
> The schematics I have are not very clear on that, but now that you
> mention this, it's most likely the case.

I hope not. That would be very broken. As Russell pointed out, MDIO is
not multi-master. You need to check with the hardware designer if the
schematics are not clear.

> Good point, but it's worse than that: when MAC0 is unbound, it will
> unregister the MDIO bus and destroy all PHY devices. These are not
> refcounted so they will literally go from under MAC1. Not sure how
> this can be dealt with?

unbinding is not a normal operation. So i would just live with it, and
if root decides to shoot herself in the foot, that is her choice.

Andrew