From: ryan@bluewatersys.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pio: add arch specific gpio_is_valid() function
Date: Tue, 07 Sep 2010 16:07:31 +1200 [thread overview]
Message-ID: <4C85BA83.9080002@bluewatersys.com> (raw)
In-Reply-To: <AANLkTi=B7O9jDB_pzHS6feWTxHQTfDZ-QLx7jOKaA2vN@mail.gmail.com>
On 09/07/2010 03:54 PM, Eric Miao wrote:
> On Tue, Sep 7, 2010 at 10:44 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
>> On 09/07/2010 02:23 PM, David Brownell wrote:
>>> Still not liking or accepting this proposed
>>> change to the GPIO framework.
>>>
>>> For the AT91 case (where integers 0..N are
>>> IRQs, but N..max are GPIOs)
>>>
>>> A simpler solution is just to use a bit in
>>> the integer to indicate IRQ vs GPIO. Like
>>> maybe the sign bit.. which is never set on
>>> valid GPIO numbers, but platforms could let
>>> be set on IRQs.
>>>
>> How about this approach instead?
>>
>
> This doesn't solve the problem with more complicated settings, e.g.
> some GPIOs within are not valid, not just the begining ones.
Agreed, but this does solve the immediate problem for AT91 in a simple
way. Are there boards in the kernel which have holes in the gpio layout?
Another possible solution is to loop through all the gpio_chips to see
if the number maps to a valid gpio. The obvious downside to this
approach is that the complexity of gpio_is_valid becomes reasonably high
for something which should be a very simple test and, as you say below,
we probably just don't need that fine-grained information.
> So the real question here is the semantics of gpio_is_valid(). I'd
> personally incline it reads as if a GPIO _number_ is valid generally,
> (e.g. like -1 is not a valid GPIO number), instead of that specific
> GPIO is valid on that specific platform. The latter can be judged
> with gpio_request().
Some drivers in the kernel appear to be using this behaviour to have
optional gpios, ie setting the foo_gpio = -1 in the platform data for
some driver. The documentation also suggests that this is what
gpio_is_valid is intended for. However, the documentation also says we
may want gpio_is_valid to return invalid on some other numbers.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
WARNING: multiple messages have this Message-ID (diff)
From: Ryan Mallon <ryan@bluewatersys.com>
To: Eric Miao <eric.y.miao@gmail.com>
Cc: David Brownell <david-b@pacbell.net>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
linux-kernel@vger.kernel.org, avictor.za@gmail.com,
bn@niasdigital.com,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] pio: add arch specific gpio_is_valid() function
Date: Tue, 07 Sep 2010 16:07:31 +1200 [thread overview]
Message-ID: <4C85BA83.9080002@bluewatersys.com> (raw)
In-Reply-To: <AANLkTi=B7O9jDB_pzHS6feWTxHQTfDZ-QLx7jOKaA2vN@mail.gmail.com>
On 09/07/2010 03:54 PM, Eric Miao wrote:
> On Tue, Sep 7, 2010 at 10:44 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
>> On 09/07/2010 02:23 PM, David Brownell wrote:
>>> Still not liking or accepting this proposed
>>> change to the GPIO framework.
>>>
>>> For the AT91 case (where integers 0..N are
>>> IRQs, but N..max are GPIOs)
>>>
>>> A simpler solution is just to use a bit in
>>> the integer to indicate IRQ vs GPIO. Like
>>> maybe the sign bit.. which is never set on
>>> valid GPIO numbers, but platforms could let
>>> be set on IRQs.
>>>
>> How about this approach instead?
>>
>
> This doesn't solve the problem with more complicated settings, e.g.
> some GPIOs within are not valid, not just the begining ones.
Agreed, but this does solve the immediate problem for AT91 in a simple
way. Are there boards in the kernel which have holes in the gpio layout?
Another possible solution is to loop through all the gpio_chips to see
if the number maps to a valid gpio. The obvious downside to this
approach is that the complexity of gpio_is_valid becomes reasonably high
for something which should be a very simple test and, as you say below,
we probably just don't need that fine-grained information.
> So the real question here is the semantics of gpio_is_valid(). I'd
> personally incline it reads as if a GPIO _number_ is valid generally,
> (e.g. like -1 is not a valid GPIO number), instead of that specific
> GPIO is valid on that specific platform. The latter can be judged
> with gpio_request().
Some drivers in the kernel appear to be using this behaviour to have
optional gpios, ie setting the foo_gpio = -1 in the platform data for
some driver. The documentation also suggests that this is what
gpio_is_valid is intended for. However, the documentation also says we
may want gpio_is_valid to return invalid on some other numbers.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
next prev parent reply other threads:[~2010-09-07 4:07 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-17 16:29 [PATCH 0/2] mmc: atmel-mci: introduce MCI2 support on at91 Nicolas Ferre
2009-09-17 16:29 ` [PATCH 1/2] atmel-mci: change use of dma slave interface Nicolas Ferre
2009-09-29 19:29 ` Andrew Morton
2009-09-29 19:29 ` Andrew Morton
2009-09-30 13:33 ` Nicolas Ferre
2009-09-30 13:55 ` Haavard Skinnemoen
2009-10-23 16:34 ` [PATCH 0/2 v2]mmc: atmel-mci: introduce MCI2 support on at91 Nicolas Ferre
2009-10-23 16:34 ` Nicolas Ferre
2009-10-23 16:34 ` [PATCH 1/3 v2] atmel-mci: change use of dma slave interface Nicolas Ferre
2009-10-23 16:34 ` Nicolas Ferre
2009-10-23 16:34 ` Nicolas Ferre
2009-10-23 16:34 ` [PATCH 2/3 v2] mmc: atmel-mci: New MCI2 module support in atmel-mci driver Nicolas Ferre
2009-10-23 16:34 ` Nicolas Ferre
2009-11-02 17:18 ` Nicolas Ferre
2009-11-02 17:18 ` Nicolas Ferre
2009-11-18 13:33 ` Nicolas Ferre
2009-11-18 13:33 ` Nicolas Ferre
2009-10-23 16:34 ` [PATCH 3/3 v2] at91/atmel-mci: inclusion of sd/mmc driver in at91sam9g45 chip and board Nicolas Ferre
2009-10-23 16:34 ` Nicolas Ferre
2009-10-26 8:15 ` Yegor Yefremov
2009-10-26 8:15 ` Yegor Yefremov
2009-11-02 17:14 ` Nicolas Ferre
2009-11-02 17:14 ` Nicolas Ferre
2009-10-27 19:43 ` Andrew Victor
2009-10-27 19:43 ` Andrew Victor
2009-10-27 19:43 ` Andrew Victor
2009-10-28 0:35 ` Haavard Skinnemoen
2009-10-28 0:35 ` Haavard Skinnemoen
2009-10-28 0:35 ` Haavard Skinnemoen
2009-10-28 0:53 ` Thiago A. Corrêa
2009-10-28 0:53 ` Thiago A. Corrêa
2009-10-28 0:53 ` Thiago A. Corrêa
2009-10-28 1:31 ` Haavard Skinnemoen
2009-10-28 1:31 ` Haavard Skinnemoen
2009-10-28 1:31 ` Haavard Skinnemoen
2009-10-28 19:53 ` Andrew Victor
2009-10-28 19:53 ` Andrew Victor
2009-10-28 19:53 ` Andrew Victor
2009-10-28 20:50 ` Ben Nizette
2009-10-28 20:50 ` Ben Nizette
2009-10-28 20:50 ` Ben Nizette
2009-11-02 17:11 ` Nicolas Ferre
2009-11-02 17:11 ` Nicolas Ferre
2009-11-02 22:10 ` Ben Nizette
2009-11-02 22:10 ` Ben Nizette
2009-11-02 22:14 ` Ben Nizette
2009-11-02 22:14 ` Ben Nizette
2009-11-03 2:30 ` Ryan Mallon
2009-11-03 2:30 ` Ryan Mallon
2009-11-03 2:30 ` Ryan Mallon
2009-11-03 2:55 ` Ben Nizette
2009-11-03 2:55 ` Ben Nizette
2009-11-07 11:20 ` Haavard Skinnemoen
2009-11-07 11:20 ` Haavard Skinnemoen
2010-08-23 15:01 ` [PATCH] pio: add arch specific gpio_is_valid() function Nicolas Ferre
2010-08-23 15:01 ` Nicolas Ferre
2010-08-23 16:36 ` David Brownell
2010-08-23 16:36 ` David Brownell
2010-08-24 8:19 ` Nicolas Ferre
2010-08-24 8:19 ` Nicolas Ferre
2010-09-06 14:21 ` [PATCH v2] AT91: pio: add " Nicolas Ferre
2010-09-06 14:21 ` Nicolas Ferre
2010-09-07 1:51 ` David Brownell
2010-09-07 1:51 ` David Brownell
2010-09-03 16:41 ` [PATCH] pio: add arch specific " Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 16:41 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-07 2:23 ` David Brownell
2010-09-07 2:23 ` David Brownell
2010-09-07 2:44 ` Ryan Mallon
2010-09-07 2:44 ` Ryan Mallon
2010-09-07 3:54 ` Eric Miao
2010-09-07 3:54 ` Eric Miao
2010-09-07 4:07 ` Ryan Mallon [this message]
2010-09-07 4:07 ` Ryan Mallon
2010-09-07 4:19 ` Eric Miao
2010-09-07 4:19 ` Eric Miao
2010-09-07 4:26 ` Ryan Mallon
2010-09-07 4:26 ` Ryan Mallon
2010-09-07 18:10 ` David Brownell
2010-09-07 18:10 ` David Brownell
2010-09-07 19:13 ` avictor.za at gmail.com
2010-09-07 19:13 ` avictor.za
2010-09-07 19:30 ` Ryan Mallon
2010-09-07 19:30 ` Ryan Mallon
2010-09-07 21:22 ` Alan Cox
2010-09-07 21:22 ` Alan Cox
2010-09-07 23:44 ` David Brownell
2010-09-07 23:44 ` David Brownell
2010-09-08 0:11 ` Alan Cox
2010-09-08 0:11 ` Alan Cox
2010-09-07 6:33 ` David Brownell
2010-09-07 6:33 ` David Brownell
2010-09-07 8:41 ` Ben Nizette
2010-09-07 8:41 ` Ben Nizette
2010-09-07 17:32 ` David Brownell
2010-09-07 17:32 ` David Brownell
2009-09-17 16:29 ` [PATCH 2/2] mmc: atmel-mci: New MCI2 module support in atmel-mci driver Nicolas Ferre
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=4C85BA83.9080002@bluewatersys.com \
--to=ryan@bluewatersys.com \
--cc=linux-arm-kernel@lists.infradead.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 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.