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: <fa686aa41002101112o66a74f60jc65fdffb48fd7213@mail.gmail.com>
Date:	Wed, 10 Feb 2010 12:12:14 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	"M. Warner Losh" <imp@...imp.com>
Cc:	scottwood@...escale.com, netdev@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org, afleming@...escale.com
Subject: Re: phy address in the device tree, vs auto probing

On Wed, Feb 10, 2010 at 11:37 AM, M. Warner Losh <imp@...imp.com> wrote:
> In message: <4B72FAB2.5000804@...escale.com>
>            Scott Wood <scottwood@...escale.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.
--
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