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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ