Re: binding for scanning a MDIO bus

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Nov 22, 2019 at 12:31:30PM +0000, Alexandru Marginean wrote:
> Hi everyone,
> 
> I am looking for the proper binding to scan for a PHY on an MDIO bus 
> that's not a child of the Ethernet device but otherwise is associated 
> with it.  Scanning this bus should guarantee finding the correct PHY, if 
> one exists.  As far as I can tell current bindings don't allow such 
> association, although the code seems to support it.
> 
> The hardware that I'm using and could use such a binding is a NXP QDS 
> board with PHY cards.  In particular this is a LS1028A, but the problem 
> is common to the NXP QDS boards.  These cards wire MDIO up to the CPU 
> through a mux.  The mux practically selects one of the slots/cards so 
> the MDIO bus the PHY is on is private to the slot/card.
> Each slot is also associated with an Ethernet interface, this is subject 
> to serdes configuration and specifically for that I'm looking to apply a 
> DT overlay.  Overlays are really impractical with the PHY cards though, 
> there are several types of cards, number of slots can go up to 8 or so 
> on some types of QDS boards and number of PHY card overlays that should 
> be defined would blow up.  The number of overlays users would need to 
> apply at boot would also go up to number of slots + 1.
> 
> The function of_mdiobus_register does scan for PHYs if 'reg' is missing 
> in PHY nodes, is this code considered obsolete, is it OK to use it if 
> needed but otherwise discouraged?  Any thoughts on including support for 
> scanning in the binding document, like making 'reg' property in phy 
> nodes optional?
> 
> For what is worth scanning is a good solution in some cases, better than 
> others anyway.  I'm sure it's not just people being too lazy to set up 
> 'reg' that use this code.

Hi Alexandru

You often see the bus registered using mdiobus_register(). That then
means a scan is performed and all phys on the bus found. The MAC
driver then uses phy_find_first() to find the first PHY on the bus.
The danger here is that the hardware design changes, somebody adds a
second PHY, and it all stops working in interesting and confusing
ways.

Would this work for you?

      Andrew