phy address in the device tree, vs auto probing

[Mitch Bradley]

>
>>
>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn at xilinx.com> wrote:
>>  
>>>> >> -----Original Message-----
>>>> >> From: glikely at secretlab.ca [mailto:glikely at secretlab.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 at xilinx.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 at 81000000 {
>>> >                        #address-cells = <1>;
>>> >                        #size-cells = <1>;
>>> >                        phy-handle = <&phy0>;
>>> >                        mdio {
>>> >                                #address-cells = <1>;
>>> >                                #size-cells = <0>;
>>> >                                phy0: phy at 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 at 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 at 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.