netdev - 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-next>] [day] [month] [year] [list]

Message-ID: <7b6fc87b-b6d8-21e6-bd8d-74c72b3d63a7@nxp.com>
Date:   Fri, 22 Nov 2019 12:31:30 +0000
From:   Alexandru Marginean <alexandru.marginean@....com>
To:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>
CC:     network dev <netdev@...r.kernel.org>,
        Grygorii Strashko <grygorii.strashko@...com>
Subject: binding for scanning a MDIO bus

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.

Thank you!
Alex