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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.