Messages in this thread | | | Date | Tue, 5 Jul 2022 21:48:58 +0200 | From | Andrew Lunn <> | Subject | Re: [PATCH net-next v2] net: macb: In shared MDIO usecase make MDIO producer ethernet node to probe first |
| |
> > Thanks for the review. I want to get your thoughts on the outline of > > the generic solution. Is the current approach fine and we can extend it > > for all shared MDIO use cases/ or do we see any limitations? > > > > a) Figure out if the MDIO bus is shared. (new binding or reuse existing) > > b) If the MDIO bus is shared based on DT property then figure out if the > > MDIO producer platform device is probed. If not, defer MDIO consumer > > MDIO bus registration. > > Radhey, > > I think Andrew added me because he's pointing you towards fw_devlink. > > Andrew, > > I have intentionally not added phy-handle support to fw_devlink > because it would also prevent the generic driver from binding/cause > issues with DSA. I have some high level ideas on fixing that but > haven't gotten around to it yet.
I took a quick look at macb, and i think it is actually broken in other ways. If you where to use NFS root, i suspect it would also fail.
This also has nothing to do with shared MDIO busses as such. All it requires is some other MDIO bus, not the MACs own MDIO bus.
It is also that we cannot return -EPROBE_DEFER when trying to connect the PHY, because it is not performed in the context of the probe, but the open.
fw_dewlink might help solve this, bit it is not going to be easy. We can also split this into two problems;
1) probe time 2) suspend/resume
macb does seem to probe, for most use cases. So we can probably ignore that for now. So we can concentrate on suspend/resume. You say suspend/resume is based on probe order. So it must build some sort of tree. Can we make phy_attach_direct add an additional link to this tree when a MAC device is link to a PHY? Is this what device_link_add() is about?
Andrew
| |