netdev - Re: binding for scanning a MDIO bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Nov 2019 16:09:32 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Alexandru Marginean <alexandru.marginean@....com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        network dev <netdev@...r.kernel.org>,
        Grygorii Strashko <grygorii.strashko@...com>
Subject: Re: binding for scanning a MDIO bus

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