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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131216233737.GL3185@sirena.org.uk>
Date:	Mon, 16 Dec 2013 23:37:37 +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 03:06:22PM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@...nel.org> [131216 13:42]:
> > On Mon, Dec 16, 2013 at 01:05:13PM -0800, Tony Lindgren wrote:

> > > Personally I don't see any value for a regulator describing the names of
> > > the GPIOs in the binding, it's really up to the driver to make sense of
> > > them. Especially if there are one or more similar GPIOs. We're not

> > Devices like PMICs frequently have a *lot* of possible pin functions
> > some of which can get mapped onto GPIOs (in either direction), many of
> > which are going to be fixed by system design and generally all muxed
> > onto a much smaller set of physical pins.  If you try to specify those

> That's why PMICs usually show up as GPIO controllers. And if a regulator
> needs to use those GPIOs, it should most likely just use the standard
> "gpios" property.

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
regulator bit either).  A lot of these things get done either to bypass
register I/O or because they are used as part of power up/down
sequencing and need to be done by hardware.  

If there's any overlap it's with pinctrl though you still need to map
the connected functions to any software controllable GPIOs they're
connected to.

> > > I don't think there should be any named GPIOs. If we want names, then
> > > the GPIO usage should be possible to group quite easily rather than create
> > > a new property for everything. Something like "enable-gpio" comes to mind.

> > I don't understand the difference between your suggestion and named
> > GPIOs.

> What I'm trying to say is let's not let drivers invent their random
> *-gpio[s] property as those essentially creates new kernel ABIs that
> we're stuck with.

> Instead, let's try to use standard properties where possible like
> "gpios" and "enable-gpios", "cs-gpios" and so on.

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

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