linux-kernel - Re: [PATCH] pio: add arch specific gpio_is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Sep 2010 16:26:37 +1200
From:	Ryan Mallon <ryan@...ewatersys.com>
To:	Eric Miao <eric.y.miao@...il.com>
CC:	David Brownell <david-b@...bell.net>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	linux-kernel@...r.kernel.org, avictor.za@...il.com,
	bn@...sdigital.com,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	linux-arm-kernel@...ts.infradead.org
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@...ewatersys.com> wrote:
>> On 09/07/2010 03:54 PM, Eric Miao wrote:
>>> On Tue, Sep 7, 2010 at 10:44 AM, Ryan Mallon <ryan@...ewatersys.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@...ewatersys.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/