Messages in this thread | | | Date | Tue, 07 Sep 2010 16:26:37 +1200 | From | Ryan Mallon <> | Subject | Re: [PATCH] pio: add arch specific gpio_is_valid() function |
| |
On 09/07/2010 04:19 PM, Eric Miao wrote: > On Tue, Sep 7, 2010 at 12:07 PM, Ryan Mallon <ryan@bluewatersys.com> wrote: >> 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. > > Right. So I'd really like David to make the semantics clear. My intention > is to keep gpio_is_valid() as simple as checking a general range to > rule out most invalid cases. And just use gpio_request() to handle the > platform specific cases.
Agreed. The intent of my patch was to keep gpio_is_valid simple, but add a simple check for architectures where the base gpio is not zero. Will wait and see what David has to say.
~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
| |