linux-kernel - Re: [PATCH] regulator: Start using standard gpios property and deprecate some custom properties

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:	Mon, 16 Dec 2013 20:11:02 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Tony Lindgren <tony@...mide.com>
Cc:	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	Tomasz Figa <t.figa@...sung.com>,
	Olof Johansson <olof@...om.net>
Subject: Re: [PATCH] regulator: Start using standard gpios property and
 deprecate some custom properties

On Mon, Dec 16, 2013 at 11:40:23AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@...nel.org> [131216 10:37]:

> > If the issue is typos then I'm not convinced that for singular GPIOs
> > it's going to be helpful, either way is prone to typos.  If the problem
> > is error reporting then that seems like a more important thing to fix.

> Are you serious? A typo here in the binding leads to silent errors where
> nothing happens with the GPIO. That's just totally messed up considering
> we use "gpios" instead of "gpio" everywhere else. So both "gpio" and
> "gpios" should be parsed for sure.

This is the first time anyone's mentioned this so it probably isn't that
serious an issue and bear in mind that the patch was also handling all
the named GPIO specifiers too.

In any case, the thing is that there's a difference between parsing both
and deprecation - deprecation implies an intention to remove the old one
which would just reintroduce the problem the other way around since
people are likely to drop or forget the plural, use old DTs and so on.
Adding a gpios property in parallel with plain gpio is fine and what I
was mostly suggesting.

> > To be honest I'm also struggling to summon up the enthusiasm for the
> > churn in the bindings, especially without going through and updating all
> > the boards (and all the other GPIO properties in various DTs).  It seems
> > like there's stuff missing in the helpers here, if we really wanted to
> > force the properties to have -gpios on the end of their names then we
> > should've had that being added by the helpers.

> Sounds like exposing an infinite number of random *-gpio and *-gpios
> bindings is a topic for another discussion. Anyways it's already totally
> out of control so what do I care.

Exactly, I think it's way more trouble than it's worth to try to change
for named single element lists.  The standard property makes more sense.

The root of the issue is that the GPIO binding originally said that
everything should use a single gpios property for everything but that's
got usability issues.  The attempt to require a -gpios suffix was a
later addition but it was just put into the binding with no real effort
to propagate it through integration with the helpers or whatever.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)