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

quoted

On Wed, Feb 10, 2010 at 9:52 AM, John Linn [off-list ref] wrote:
 

quoted

quoted

quoted

quoted

-----Original Message-----
From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On 

Behalf Of Grant Likely

quoted

quoted

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 [off-list ref] 

wrote:
     

quoted

quoted

quoted

quoted

Hi Grant,

I notice that the OF driver for the mdio bus is not doing 

auto probing.

quoted

quoted

quoted

As we start putting in the phy layer in the emac drivers, the 

device

quoted

quoted

quoted

trees tend to have the phy address in them, but we're not 

sure we really

quoted

quoted

quoted

like that.

We really think that being able to let the kernel find the 

phy address

quoted

quoted

quoted

is a big benefit, otherwise this is one other piece of info 

the user has

quoted

quoted

quoted

to know and get right.

Am I missing something here?

quoted

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

quoted

quoted

bus.

In the simple case where there is a one:one:one relationship 

between

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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.

quoted

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?

quoted

               Ethernet_MAC: ethernet@81000000 {
                       #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.

quoted

                               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.

FYI, wildcard matching is defined in section 4.3.3 clause (b) and 
section 4.3.5 of IEEE 1275-1994.