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]

Message-ID: <a6f797cf-956e-90d9-0bb3-11e752b8a818@nxp.com>
Date:   Fri, 22 Nov 2019 16:20:41 +0000
From:   Alexandru Marginean <alexandru.marginean@....com>
To:     Andrew Lunn <andrew@...n.ch>
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

Hi Andrew,

On 11/22/2019 4:09 PM, Andrew Lunn wrote:
> 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
> 

How does the MAC get a reference to the mdio bus though, is there some 
way to describe this relationship in the DT?  I did say that Eth and 
mdio are associated and they are, but not in the way Eth would just know 
without looking in the DT what mdio that is.  It's only that one such 
mdio exists for a given Eth and it's safe to use, but Eth needs to be 
told where to find it and that information should come from the DT.

Mdio buses of slots/cards are defined in DT under the mdio mux.  The mux 
itself is accessed over I2C and its parent-mdio is a stand-alone device 
that is not associated with a specific Ethernet device.  And on top of 
that, based on serdes configuration, some Eth interfaces may end up on a 
different slot and for that I want to apply a DT overlay to set the 
proper Eth/mdio association.

Current code allows me to do something like this, as seen by Linux on boot:
/ {
....
	mdio-mux {
		/* slot 1 */
		mdio@4 {
			slot1_phy0: phy {
				/* 'reg' missing on purpose */
			};
		};
	};
....
};

&enetc_port0 {
	phy-handle = <&slot1_phy0>;
	phy-mode = "sgmii";
};

But the binding does not allow this, 'reg' is a required property of 
phys.  Is this kind of DT structure acceptable even if it's not 
compliant to the binding?  Assuming it's fine, any thoughts on making 
this official in the binding?  If it's not, are there alternative 
options for such a set-up?

Thanks!
Alex