linux-kernel - Re: [PATCH V1] regulator: fixed: dt: add property for gpio open drain flag

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

Date:	Wed, 9 May 2012 11:14:28 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Laxman Dewangan <ldewangan@...dia.com>,
	"lrg@...com" <lrg@...com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH V1] regulator: fixed: dt: add property for gpio open
 drain flag

On Tue, May 08, 2012 at 03:26:16PM -0600, Stephen Warren wrote:
> On 05/07/2012 10:24 AM, Mark Brown wrote:

> > It's really not idiomatic for drivers using GPIOs to allow
> > configuration of their flags in the first place.  Or, quite
> > frankly, to use flags. Honestly I'd not expect any bindings that
> > the GPIO driver provides to have any attention at all paid to them
> > most of the time, looking at the code seems to support that (though
> > there's surprisingly few bindings using GPIOs at all it seems).

> So, are you saying we should remove the flags from the GPIO bindings,
> and do something custom in each consumer?

Not really, it's more internal Linux stuff with the gpio API being a bit
stuck.

> Right now, we can't rely on of_get_gpio_flags(), since not all GPIO
> drivers actually allow flags to be represented in bindings.

> However, having each client have a unique binding for things like
> open-drain, inverted, ... seems bad; there are probably fewer
> providers than consumers, although a single standardized

It really depends what the device is doing with the GPIO, we would at
least need to have a way for the user to get the flags back out in case
the configuration is important for what it does.  Most of this stuff is
going to be nonsensical for most uses anyway, though, and obviously
there's the whole middleware emulation thing as well.

> representation might admittedly have been ever better.

Well, that's legacy device tree stuff for you :/

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