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: <20131216183615.GK3185@sirena.org.uk>
Date:	Mon, 16 Dec 2013 18:36:15 +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 Fri, Dec 13, 2013 at 12:07:14PM -0800, Tony Lindgren wrote:
> We can start moving regulators to using the standard gpios property instead
> of various custom GPIO related properties. The reason for doing this is that
> at least regulator-fixed can currently cause silent bugs if "gpios" property
> is used instead of "gpio" property.

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.

> Fix the issue by trying to use "gpios" where possible in the drivers that
> can already use it, and if that fails, then try to use the deprecated custom
> property for getting the GPIO.

Please split stuff like this up per driver rather than just sending a
jumbo patch for the subsystem, it makes it much easier to review
especially when they're not all doing exactly the same thing.

> -  - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
> +  - gpios: GPIO specifier for external DVS pin control of LP872x devices.

This is definitely a step backwards, it's changing from a named property
which does a specific thing to a property with no useful semantics in
the name.  That would be a step backwards for both legibility and
extensibility, if support for any other GPIO controlled features is
added then adding them into the sam property is going to be unpleasant
and lead to the usability failures so typical of the older device tree
bindings.  The the binding document says to use a name prefix, not to
call everything just "gpios".

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ