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

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

[Grant Likely]

(cc'ing devicetree-discuss and netdev mailing lists)

On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> 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.

g.

>
> Thanks,
> John
>
>
> int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> {
>        struct phy_device *phy;
>        struct device_node *child;
>        int rc, i;
>
>        /* Mask out all PHYs from auto probing.  Instead the PHYs listed
> in
>         * the device tree are populated after the bus has been
> registered */
>        mdio->phy_mask = ~0;
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[John Linn]

> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@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@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@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.

		Ethernet_MAC: ethernet@81000000 {
			#address-cells = <1>;
			#size-cells = <1>;
			phy-handle = <&phy0>; 
			mdio {
				#address-cells = <1>;
				#size-cells = <0>;
				phy0: phy@7 {
					reg = <-1>;
				} ; 
			} ;

> 
> g.
> 
> >
> > Thanks,
> > John
> >
> >
> > int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> > {
> >        struct phy_device *phy;
> >        struct device_node *child;
> >        int rc, i;
> >
> >        /* Mask out all PHYs from auto probing.  Instead the PHYs listed
> > in
> >         * the device tree are populated after the bus has been
> > registered */
> >        mdio->phy_mask = ~0;
> >
> > This email and any attachments are intended for the sole use of the named recipient(s) and
> contain(s) confidential information that may be proprietary, privileged or copyrighted under
> applicable law. If you are not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any attachments immediately.
> >
> >
> >
> 
> 
> 
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

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

[Grant Likely]

On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>> -----Original Message-----
>> From: glikely@secretlab.ca [mailto:glikely@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@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@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.
>                                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?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[Scott Wood]

Grant Likely wrote:
>> 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@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.
>>                                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?

I'm not fond of the -1.  I'd prefer the explicit phy-probe-address property, 
though I don't mind too much using the absence of reg.

-Scott

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

[Mitch Bradley]

>
> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>   
>>> >> -----Original Message-----
>>> >> From: glikely@secretlab.ca [mailto:glikely@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@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@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.
>> >                                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.

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

[Mitch Bradley]

>
>>
>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>  
>>>> >> -----Original Message-----
>>>> >> From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] 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-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> 
>>>> 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@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.
>>> >                                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.

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

[M. Warner Losh]

In message: <4B72FAB2.5000804-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
            Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
: Grant Likely wrote:
: >> 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@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.
: >>                                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?
: 
: I'm not fond of the -1.  I'd prefer the explicit phy-probe-address
: property, though I don't mind too much using the absence of reg.

There are times that you'd want a list of PHY addresses to use.  This
suggests a bitmask, but I don't know if they are common enough to
warrant the extra burden on the usual case...

Warner

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

[Fleming Andy-AFLEMING]

On Feb 10, 2010, at 12:15, "Grant Likely" <grant.likely@secretlab.ca>  
wrote:

> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com>  
> wrote:
>>> -----Original Message-----
>>> From: glikely@secretlab.ca [mailto:glikely@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@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@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.
>>                                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.

I don't think it's necessary that only one phy node is there.  I don't  
think the of mdio layer should set policy, here.  Some drivers hard  
code their addresses.  Some drivers assume (foolishly, I think) that  
the PHYs are in order.  Many assume there's only one PHY.  I think the  
mdio driver should set policy, so of_mdio should just allow for PHYs  
to be probed.  I'm actually not sure that requires any changes.  Quite  
possibly this just means that of_mdio is not appropriate for such a  
driver.   The standard PHY code supports this sort of thing.

I don't think this can reasonably be done with of_phy_connect(),  
because not every driver will want the same behavior.

If you can't have your bootloader modify the tree to have addresses  
(and then it can do the probe however it wants, in a board-specific  
way), then you could add some board code or mdio driver code which  
modifies the device tree to have addresses.

Andy

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

[Grant Likely]

On Wed, Feb 10, 2010 at 11:37 AM, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <4B72FAB2.5000804@freescale.com>
>            Scott Wood <scottwood@freescale.com> writes:
> : Grant Likely wrote:
> : >> 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?
> :
> : I'm not fond of the -1.  I'd prefer the explicit phy-probe-address
> : property, though I don't mind too much using the absence of reg.
>
> There are times that you'd want a list of PHY addresses to use.  This
> suggests a bitmask, but I don't know if they are common enough to
> warrant the extra burden on the usual case...

Are you talking a single MAC attached to multiple PHYs?  If so, then
the current device tree binding doesn't support this, but it would be
easy to extend the current binding by making the phy-handle property a
list of phy nodes phandes.

If you're talking about a phy being able to appear at a number of
addresses, then perhaps this could be handled by simple listing the
full range of base addresses in the phy's reg property.  So for a phy
that could appear at address 2, 3, 6, or 7:

reg = <2 3 6 7>;

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[Grant Likely]

On Wed, Feb 10, 2010 at 11:40 AM, Fleming Andy-AFLEMING
<afleming@freescale.com> wrote:
>
>
> On Feb 10, 2010, at 12:15, "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>>>>
>>>> -----Original Message-----
>>>> From: glikely@secretlab.ca [mailto:glikely@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@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@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.
>>>                               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.
>
> I don't think it's necessary that only one phy node is there.  I don't think
> the of mdio layer should set policy, here.  Some drivers hard code their
> addresses.  Some drivers assume (foolishly, I think) that the PHYs are in
> order.  Many assume there's only one PHY.  I think the mdio driver should
> set policy, so of_mdio should just allow for PHYs to be probed.  I'm
> actually not sure that requires any changes.  Quite possibly this just means
> that of_mdio is not appropriate for such a driver.   The standard PHY code
> supports this sort of thing.

That still doesn't solve the problem of matching PHYs to MACs.

Consider this example:  2 MACs, 2 PHYs.  mac_a--> phy_a and mac_b -->
phy_b.  Both phys on the same mdio bus, described thus:

               eth_a: ethernet@81000000 {
                       #address-cells = <1>;
                       #size-cells = <1>;
                       phy-handle = <&phy_a>;
                       mdio {
                               #address-cells = <1>;
                               #size-cells = <0>;
                               phy_a: phy_a {
                               } ;
                               phy_b: phy_b {
                               } ;
                       } ;
               } ;
               eth_b: ethernet@82000000 {
                       #address-cells = <1>;
                       #size-cells = <1>;
                       phy-handle = <&phy_b>;
               } ;

In this example, the kernel knows it has two phys, and probing
confirms this (say at phy addresses 3 and 7).  How does the kernel
know which address phy_a responds to?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[Mark Brown]

On Wed, Feb 10, 2010 at 12:12:14PM -0700, Grant Likely wrote:
> On Wed, Feb 10, 2010 at 11:37 AM, M. Warner Losh <imp@bsdimp.com> wrote:

> > There are times that you'd want a list of PHY addresses to use. ?This
> > suggests a bitmask, but I don't know if they are common enough to
> > warrant the extra burden on the usual case...

> Are you talking a single MAC attached to multiple PHYs?  If so, then
> the current device tree binding doesn't support this, but it would be
> easy to extend the current binding by making the phy-handle property a
> list of phy nodes phandes.

There's also the entertaining case I've dealt with (pre device tree but
actually on PowerPC) where the MAC has multiple PHYs attached but they
should only be exposed to userspace and the driver should rely on MII
configuration provided by userspace without touching them.

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

[Andy Fleming]

On Feb 10, 2010, at 1:20 PM, Grant Likely wrote:

> On Wed, Feb 10, 2010 at 11:40 AM, Fleming Andy-AFLEMING
> <afleming@freescale.com> wrote:
>> 
>> 
>> On Feb 10, 2010, at 12:15, "Grant Likely" <grant.likely@secretlab.ca> wrote:
>> 
>>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>>>>> 
>>>>> -----Original Message-----
>>>>> From: glikely@secretlab.ca [mailto:glikely@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@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@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.
>>>>                               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.
>> 
>> I don't think it's necessary that only one phy node is there.  I don't think
>> the of mdio layer should set policy, here.  Some drivers hard code their
>> addresses.  Some drivers assume (foolishly, I think) that the PHYs are in
>> order.  Many assume there's only one PHY.  I think the mdio driver should
>> set policy, so of_mdio should just allow for PHYs to be probed.  I'm
>> actually not sure that requires any changes.  Quite possibly this just means
>> that of_mdio is not appropriate for such a driver.   The standard PHY code
>> supports this sort of thing.
> 
> That still doesn't solve the problem of matching PHYs to MACs.
> 
> Consider this example:  2 MACs, 2 PHYs.  mac_a--> phy_a and mac_b -->
> phy_b.  Both phys on the same mdio bus, described thus:
> 
>               eth_a: ethernet@81000000 {
>                       #address-cells = <1>;
>                       #size-cells = <1>;
>                       phy-handle = <&phy_a>;
>                       mdio {
>                               #address-cells = <1>;
>                               #size-cells = <0>;
>                               phy_a: phy_a {
>                               } ;
>                               phy_b: phy_b {
>                               } ;
>                       } ;
>               } ;
>               eth_b: ethernet@82000000 {
>                       #address-cells = <1>;
>                       #size-cells = <1>;
>                       phy-handle = <&phy_b>;
>               } ;
> 
> In this example, the kernel knows it has two phys, and probing
> confirms this (say at phy addresses 3 and 7).  How does the kernel
> know which address phy_a responds to?


There's no way to know.  That's what I'm saying.  We shouldn't modify the of_mdio code to say which PHY is which.  Instead, we have the MDIO/ethernet code do that.  And maybe this means that they can't use of_mdio.  Or maybe we need to devise a scheme so you can specify those PHYs, but delay associating them with an address until later.

Andy

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

[Grant Likely]

On Wed, Feb 10, 2010 at 12:46 PM, Andy Fleming <afleming@freescale.com> wrote:
>
> On Feb 10, 2010, at 1:20 PM, Grant Likely wrote:
>
>> On Wed, Feb 10, 2010 at 11:40 AM, Fleming Andy-AFLEMING
>> <afleming@freescale.com> wrote:
>>> I don't think it's necessary that only one phy node is there.  I don't think
>>> the of mdio layer should set policy, here.  Some drivers hard code their
>>> addresses.  Some drivers assume (foolishly, I think) that the PHYs are in
>>> order.  Many assume there's only one PHY.  I think the mdio driver should
>>> set policy, so of_mdio should just allow for PHYs to be probed.  I'm
>>> actually not sure that requires any changes.  Quite possibly this just means
>>> that of_mdio is not appropriate for such a driver.   The standard PHY code
>>> supports this sort of thing.
>>
>> That still doesn't solve the problem of matching PHYs to MACs.
>>
>> Consider this example:  2 MACs, 2 PHYs.  mac_a--> phy_a and mac_b -->
>> phy_b.  Both phys on the same mdio bus, described thus:
>>
>>               eth_a: ethernet@81000000 {
>>                       #address-cells = <1>;
>>                       #size-cells = <1>;
>>                       phy-handle = <&phy_a>;
>>                       mdio {
>>                               #address-cells = <1>;
>>                               #size-cells = <0>;
>>                               phy_a: phy_a {
>>                               } ;
>>                               phy_b: phy_b {
>>                               } ;
>>                       } ;
>>               } ;
>>               eth_b: ethernet@82000000 {
>>                       #address-cells = <1>;
>>                       #size-cells = <1>;
>>                       phy-handle = <&phy_b>;
>>               } ;
>>
>> In this example, the kernel knows it has two phys, and probing
>> confirms this (say at phy addresses 3 and 7).  How does the kernel
>> know which address phy_a responds to?
>
>
> There's no way to know.

Which is why I'm saying that when the phy address is unknown, the
binding should only allow for a single phy node.  We're talking about
how to accurately describe the platform, not how the implementation
should work.  The mdio/of_mdio changes are Linux kernel implementation
details.

>  That's what I'm saying.  We shouldn't modify the of_mdio code to say which PHY is which.  Instead, we have the MDIO/ethernet code do that.  And maybe this means that they can't use of_mdio.  Or maybe we need to devise a scheme so you can specify those PHYs, but delay associating them with an address until later.

Same problem.  even if phys are probed, the kernel doesn't know which
MAC to attach each to.  If the solution is to hard coded it into the
driver, then that is a different problem scenario than John is trying
to solve.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.