netdev - Re: [RFC PATCHv2 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20131112123746.EAEF0C42283@trevor.secretlab.ca>
Date:	Tue, 12 Nov 2013 21:37:46 +0900
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Florian Fainelli <florian@...nwrt.org>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
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>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCHv2 3/4] of: provide a binding for fixed link PHYs

On Fri, 25 Oct 2013 05:40:57 +0100, Florian Fainelli <florian@...nwrt.org> wrote:
> Le mercredi 18 septembre 2013, 18:11:12 Thomas Petazzoni a écrit :
> > Dear Grant Likely,
> > 
> > On Tue, 17 Sep 2013 23:29:23 -0500, Grant Likely wrote:
> > > I understand what you're trying to do here, but it causes a troublesome
> > > leakage of implementation detail into the binding, making the whole
> > > thing look very odd. This binding tries to make a fixed link look
> > > exactly like a real PHY even to the point of including a phandle to the
> > > phy. But having a phandle to a node which is *always* a direct child of
> > > the MAC node is redundant and a rather looney. Yes, doing it that way
> > > makes it easy for of_phy_find_device() to be transparent for fixed link,
> > > but that should *not* drive bindings, especially when that makes the
> > > binding really rather weird.
> > > 
> > > Second, this new binding doesn't provide anything over and above the
> > > existing fixed-link binding. It may not be pretty, but it is
> > > estabilshed.
> > 
> > Have you followed the past discussions about this patch set? Basically
> > the *only* feedback I received on RFCv1 is that the fixed-link property
> > sucks, and everybody (including the known Device Tree binding
> > maintainer Mark Rutland) suggested to not use the fixed-link mechanism.
> > See http://article.gmane.org/gmane.linux.network/276932, where Mark
> > said:
> > 
> > ""
> > I'm not sure grouping these values together is the best way of handling
> > this. It's rather opaque, and inflexible for future extension.
> > ""
> > 
> > So, please DT maintainers, tell me what you want. I honestly don't care
> > whether fixed-link or a separate node is chosen. However, I do care
> > about being dragged around between two solutions just because the
> > former DT maintainer and the new DT maintainers do not agree.

I've been sleepy on this issue, which limits how much I can push. I'll
say one more thing on the issue (below) and then leave the decision up
to Mark. I trust him and he knows what he is doing.

> Since I would like to move forward so I can one day use that binding in a 
> real-life product, I am going to go for Mark's side which happens to be how I 
> want the binding to look like.
> 
> Do we all agree that the new binding is just way better than the old one? In 
> light of the recent unstable DT ABI discussion, we can still continue parsing 
> the old one for the sake of compatibility.

Regardless of what you want it to look like, does the old binding work
for your purposes? If yes then use it. The only valid reason for
creating a new binding is if the old one doesn't work for a specific
(not theoretical) use case.

g.
--
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