From: Lars-Peter Clausen <lars@metafoo.de>
To: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Eric Miao <eric.y.miao@gmail.com>,
Peter Tyser <ptyser@xes-inc.com>,
linux-kernel@vger.kernel.org, Alek Du <alek.du@intel.com>,
Samuel Ortiz <sameo@linux.intel.com>,
David Brownell <dbrownell@users.sourceforge.net>,
Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Joe Perches <joe@perches.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH v2 1/4] gpiolib: Add "unknown" direction support
Date: Thu, 17 Feb 2011 14:06:06 +0100 [thread overview]
Message-ID: <4D5D1D3E.2020107@metafoo.de> (raw)
In-Reply-To: <201102171321.47704.alexander.stein@systec-electronic.com>
On 02/17/2011 01:21 PM, Alexander Stein wrote:
> On Thursday 17 February 2011, 13:03:54 Lars-Peter Clausen wrote:
>> On 02/17/2011 08:33 AM, Eric Miao wrote:
>>> On Thu, Feb 17, 2011 at 8:56 AM, Peter Tyser <ptyser@xes-inc.com> wrote:
>>>> Previously, gpiolib would unconditionally flag all GPIO pins as inputs,
>>>> regardless of their true state. This resulted in all GPIO output pins
>>>> initially being incorrectly identified as "input" in the GPIO sysfs.
>>>>
>>>> Since the direction of GPIOs is not known prior to having their
>>>> direction set, instead set the default direction to "unknown" to prevent
>>>> user confusion. A pin with an "unknown" direction can not be written or
>>>> read via sysfs; it must first be configured as an input or output before
>>>> it can be used.
>>>
>>> Hrm... that's why I don't like the original definition of gpio_request()
>>> which is vague on the pin configurations.
>>
>> Actually it doesn't say anything at all about the current configuration at
>> all. Requesting a pin grants you exclusive access to that pin, if it
>> succeeds. So it is solely about ownership and not about configuration.
>
> Well, ownership is a bit misleading here. You must request a GPIO to change
> its direction. But to set or get a value this isn't required.
Well, it is not enforced in the actual code, but the GPIO API is based on
convention and I would consider it a misusage of the API to call
gpio_{set,get}_value without requesting the pin and having configured its
direction prior to it.
> In general one could expect if you requested a GPIO you are the only one to
> call any function on it. On the other hand, this may be bad in some situations
> where you want to read a GPIO value from different places.
Sharing GPIOs in read-only mode, is indeed something that is not covered by the
GPIO API. It might be worth adding a gpio_request_shared, which would only
permit setting the direction to input. Futher gpio_request_shared calls would
be allowed but gpio_request calls would fail.
- Lars
next prev parent reply other threads:[~2011-02-17 13:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 0:56 [PATCH v2 1/4] gpiolib: Add "unknown" direction support Peter Tyser
2011-02-17 0:56 ` [PATCH v2 2/4] gpiolib: Add ability to get GPIO pin direction Peter Tyser
2011-02-17 11:00 ` Wolfram Sang
2011-02-17 0:56 ` [PATCH v2 3/4] gpio: pca953x: Implement get_direction() hook Peter Tyser
2011-02-17 0:56 ` [PATCH v2 4/4] gpio: Add support for Intel ICHx/3100/Series[56] GPIO Peter Tyser
2011-02-17 7:33 ` [PATCH v2 1/4] gpiolib: Add "unknown" direction support Eric Miao
2011-02-17 11:05 ` Uwe Kleine-König
2011-02-17 12:03 ` Lars-Peter Clausen
2011-02-17 12:21 ` Alexander Stein
2011-02-17 13:06 ` Lars-Peter Clausen [this message]
2011-02-21 9:09 ` Alexander Stein
2011-02-21 9:19 ` Wolfram Sang
2011-02-21 9:37 ` Alexander Stein
2011-02-21 9:47 ` Wolfram Sang
2011-02-21 11:07 ` Alexander Stein
2011-02-21 11:22 ` Wolfram Sang
2011-02-21 11:38 ` Alexander Stein
2011-02-21 20:25 ` Ryan Mallon
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=4D5D1D3E.2020107@metafoo.de \
--to=lars@metafoo.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=alek.du@intel.com \
--cc=alexander.stein@systec-electronic.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dbrownell@users.sourceforge.net \
--cc=eric.y.miao@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ptyser@xes-inc.com \
--cc=sameo@linux.intel.com \
--cc=u.kleine-koenig@pengutronix.de \
/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