netdev - Re: [PATCHv3 3/4] of: provide a binding for fixed link PHYs

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:	Thu, 15 May 2014 15:39:57 +0200
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, Lior Amsalem <alior@...vell.com>,
	Mark Rutland <mark.rutland@....com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Christian Gmeiner <christian.gmeiner@...il.com>,
	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	Gregory Clement <gregory.clement@...e-electrons.com>,
	Florian Fainelli <florian@...nwrt.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCHv3 3/4] of: provide a binding for fixed link PHYs

Dear Grant Likely,

Sorry for bringing back this old topic, but I'm working on this again,
hopefully reaching an acceptable solution this time. One question for
you below.

On Sat, 08 Mar 2014 05:50:33 +0000, Grant Likely wrote:

> > +Example:
> > +
> > +ethernet@0 {
> > +	...
> > +	phy = <&phy0>;
> > +	phy0: phy@0 {
> > +	      fixed-link;
> > +	      speed = <1000>;
> > +	      full-duplex;
> > +	};
> 
> The phy phandle to a child node is superfluous. A phandle to a fixed
> child node doesn't make a whole lot of sense.

[...]

> There should be no address portion in the node name. It isn't a child
> device, the node is merely more configuration data for the parent.
> 
> Example:
> 
> ethernet@0 {
> 	...
> 	fixed-link {
> 	      speed = <1000>;
> 	      full-duplex;
> 	};

For my current use case, I'm personally fine with that. But that
doesn't work well with Florian Fainelli's which to potentially have the
"fixed-link" node as part of another node in the DT, in the case the
PHY is configurable through some separate SPI/I2C bus. See his comment
in http://article.gmane.org/gmane.linux.network/306789:

"""
Another problem with that "old" 'fixed-link' property is that we are
not properly capturing and representing Ethernet switches/PHYs whose
data-path are isolated from the control path. For instance such
devices will traditionally expose their control path as a
MMIO/GPIO/I2C/SPI interface. Using the 5-digit 'fixed-link' property
we are not representing this, on one side the Ethernet MAC is just
told to hardcode the link parameters with some parameters, and on
other side, any MMIO/GPIO/I2C/SPI device is not equipped with the
correct properties to express the fact that is also has a data-path
connected to an Ethernet MAC.

What I like about this new binding is that we could place the
'fixed-link' related properties in e.g: a SPI slave node, and have the
Ethernet MAC be pointed at it by a phandle to tell it: look this is
your PHY, it might not be one you could address on a MDIO bus, so I
have been providing additional properties to help you with the link
configuration.
"""

What is your opinion about this?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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