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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Feb 2010 11:14:47 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	John Linn <John.Linn@...inx.com>
Cc:	devicetree-discuss <devicetree-discuss@...ts.ozlabs.org>,
	netdev <netdev@...r.kernel.org>,
	Andy Fleming <afleming@...escale.com>,
	Scott Wood <scottwood@...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?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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