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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 19 Dec 2013 13:26: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 Tue, Dec 17, 2013 at 07:37:27AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@...nel.org> [131216 15:39]:

> > No, that's a different thing - the PMIC will typically be able to use
> > some pins as GPIOs so most expose a GPIO controller.  The functions that
> > are an issue here are things like voltage selection, voltage transition
> > completion status, sleep mode, enable control or whatever that may need
> > to be tied to the SoC for interaction (usually not just limited to the

> OK. Maybe the best way to deal with that is to have the driver specific
> regmap (gpiomap? :) configuration describe that? And then the driver
> GPIO configuration is picked up just based on the compatible flags and
> the gpios property?

Possibly.  I'd need to see the resulting code and DTs - I'm not 100%
visualising what's meant here.

> > Oh, OK.  Yes, standardisation of the names has benefits though for some
> > of the features (especially voltage selection) the implementation gets
> > rather chip specific and there are also advantages in having the DT
> > binding correspond to the chip documentation.

> > Things that really are very standard probably ought to be being done by
> > the core anyway (like we've done with all the factoring out of standard
> > voltage map and regmap operations).

> Agreed. And a lot of that can be configured automatically based on the
> compatible property.

Hopefully not even the compatible property - we ought to just be able to
pick standard names for some of the standard functions and just support
them without any effort from drivers at all.

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