From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Laxman Dewangan <ldewangan@nvidia.com>, "lrg@ti.com" <lrg@ti.com>,
"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
"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: Mon, 7 May 2012 17:24:20 +0100 [thread overview]
Message-ID: <20120507162419.GK17002@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FA7E841.7020100@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]
On Mon, May 07, 2012 at 09:20:33AM -0600, Stephen Warren wrote:
> My point is that there's clear intent for of_gpio_simple_xlate() to
> return the GPIO flags from a field in the GPIO specifier in device tree,
> irrespective of whether some GPIO bindings don't allow this, or whether
> this is fully documented.
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).
Before we start doing stuff to improve this it feels like we should do
things like get devm_ versions of gpiolib APIs in there (since most
conversions would really benefit from that too) - I've been sending a
patch for that but my backlog of unmerged patches for it keeps getting
bigger rather than smaller.
> We shouldn't have two different mechanisms to represent this
> information. How do we resolve the situation where a particular SoC's
> GPIO binding allows the flags to be specified, and this patch allows the
> open-drain flag to be specified, and the two values are different?
> Either we should force all bindings to have some way of specifying the
> flags, or we should remove the flags from all bindings and rely on
> separate properties.
There's also the case where the bindings probably should be ignored
because the device driver knows what the connection has to be anyway and
there's no point in forcing people to encode it in the binding.
It's a real shame all these bindings are driver specific, it's just like
interrupts :(
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-05-07 16:24 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 [this message]
2012-05-08 21:26 ` Stephen Warren
2012-05-09 10:14 ` Mark Brown
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=20120507162419.GK17002@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=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).