From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: "grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
Laxman Dewangan <ldewangan@nvidia.com>, "lrg@ti.com" <lrg@ti.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH V1] regulator: fixed: dt: add property for gpio open drain flag
Date: Wed, 9 May 2012 11:14:28 +0100 [thread overview]
Message-ID: <20120509101428.GE3955@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FA98F78.4080803@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
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 :/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-05-09 10:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 10:28 [PATCH V1] regulator: fixed: dt: add property for gpio open drain flag Laxman Dewangan
2012-05-07 11:35 ` Mark Brown
2012-05-07 15:05 ` Stephen Warren
2012-05-07 15:08 ` Laxman Dewangan
2012-05-07 15:20 ` Stephen Warren
2012-05-07 16:24 ` Mark Brown
2012-05-08 21:26 ` Stephen Warren
2012-05-09 10:14 ` Mark Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120509101428.GE3955@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=ldewangan@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).