netdev - Re: phy address in the device tree, vs auto probing

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: <4B72FB38.7080909@firmworks.com>
Date:	Wed, 10 Feb 2010 08:30:16 -1000
From:	Mitch Bradley <wmb@...mworks.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	John Linn <John.Linn@...inx.com>,
	Scott Wood <scottwood@...escale.com>,
	netdev <netdev@...r.kernel.org>,
	devicetree-discuss <devicetree-discuss@...ts.ozlabs.org>,
	Andy Fleming <afleming@...escale.com>
Subject: Re: phy address in the device tree, vs auto probing

>
> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@...inx.com> wrote:
>   
>>> >> -----Original Message-----
>>> >> From: glikely@...retlab.ca [mailto:glikely@...retlab.ca] On Behalf Of Grant Likely
>>> >> Sent: Wednesday, February 10, 2010 9:44 AM
>>> >> To: John Linn; devicetree-discuss; netdev
>>> >> Subject: Re: phy address in the device tree, vs auto probing
>>> >>
>>> >> (cc'ing devicetree-discuss and netdev mailing lists)
>>> >>
>>> >> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn@...inx.com> wrote:
>>>       
>>>> >> > Hi Grant,
>>>> >> >
>>>> >> > I notice that the OF driver for the mdio bus is not doing auto probing.
>>>> >> >
>>>> >> > As we start putting in the phy layer in the emac drivers, the device
>>>> >> > trees tend to have the phy address in them, but we're not sure we really
>>>> >> > like that.
>>>> >> >
>>>> >> > We really think that being able to let the kernel find the phy address
>>>> >> > is a big benefit, otherwise this is one other piece of info the user has
>>>> >> > to know and get right.
>>>> >> >
>>>> >> > Am I missing something here?
>>>>         
>>> >>
>>> >> No, you're not really missing something, but there is an inherent
>>> >> complexity in what you're wanting to do.  Like i2c, MDIO is one of
>>> >> those busses that is hard to probe reliable.  Some PHYs respond on
>>> >> more than one address, and there is no way to determine which MAC a
>>> >> PHY is wired up to.  Many PHYs can live on a single MDIO bus.  MACs
>>> >> with their own MDIO busses may still get wired to a PHY on a different
>>> >> bus.
>>> >>
>>> >> In the simple case where there is a one:one:one relationship between
>>> >> MAC, MDIO bus and PHY, then it should be okay to probe the PHY,
>>> >> correct?  The question then must be asked; how does the kernel
>>> >> determine that it can use the simple case?  Nobody has yet defined a
>>> >> way to describe that in the device tree; mostly because nobody has
>>> >> needed to yet.
>>> >>
>>> >> So, it is possible to do what you want, but you need a way to
>>> >> *explicitly* ask for that behaviour.  ie, some way to indicate in a
>>> >> MAC node which MDIO bus the phy is on, and that the phy needs to be
>>> >> probed for.  I think this should only be an option when the MDIO bus
>>> >> has only one PHY.  Come up with a proposal and post it to the
>>> >> devicetree-discuss mailing list.
>>>       
>> >
>> > Here's a couple ideas. See what everyone thinks as I'm not stuck on either.
>> >
>> > Thanks,
>> > John
>> >
>> > 1. What if we just don't specific a phy address with a reg property which would specify to auto probe it and find the phy as illustrated below?
>> >
>> >
>> >                Ethernet_MAC: ethernet@...00000 {
>> >                        #address-cells = <1>;
>> >                        #size-cells = <1>;
>> >                        phy-handle = <&phy0>;
>> >                        mdio {
>> >                                #address-cells = <1>;
>> >                                #size-cells = <0>;
>> >                                phy0: phy@7 {
>> >                                } ;
>> >                        } ;
>> >
>> > 2. Or a special value (-1 or something not 0 - 31) in the phy address that specifies to auto probe as illustrated below.
>> >                                phy0: phy@7 {
>> >                                        reg = <-1>;
>> >                                } ;
>>     
>
> I don't like abusing the reg property in this way.  I wonder if a new
> empty property would be a better way to indicate this.  Maybe
> "phy-probe-address;"?  It would also be important to specify in the
> binding that only one phy node is allowed when phy-probe-address is
> used.
>
> Also, without a known reg the 'phy@7' name is inaccurate.  Drop the @7.
>
> Scott, Andy: any thoughts?
>   

This case is somewhat similar to "wildcard nodes" on unprobed SCSI 
buses, going all the way back to pre-1275 Open Boot.  Since full probing 
of a SCSI bus could take a really long time (spin-up delays etc), Open 
Boot would usually create a bus node for the host controller and 
populate it with a disk node and a tape node, neither of which had a reg 
property.  That meant that there was a good chance that you might find 
such devices on that bus, but their specific SCSI bus addresses had not 
yet been determined.  In addition to those wildcard nodes, similar nodes 
with extant reg properties could also appear, asserting the presence of 
a known device at the given address.  The node matching algorithm first 
looks for an exact match with a reg property, and failing that, looks 
for a wildcard match.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html