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]
Message-Id: <0D5B5291-80B9-4576-8DC7-8F33CFF2A803@niasdigital.com>
Date:	Tue, 7 Sep 2010 18:41:38 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Ryan Mallon <ryan@...ewatersys.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	avictor.za@...il.com
Subject: Re: [PATCH] pio: add arch specific gpio_is_valid() function


On 07/09/2010, at 4:33 PM, David Brownell wrote:

> 
> 
> --- On Mon, 9/6/10, Ryan Mallon <ryan@...ewatersys.com> wrote:
> 
> 
>> How about this approach instead?
> 
> Still don't like it, sorry.  gpio_is_valid()
> is not intended as a fine-grained call, there is
> a call which is fine grained; use that instead.
> 

I've been sitting on the sidelines but it seems like the below might
help :-)

---8K---

A recent discussion on LKML [1] highlighted some confusion regarding the
semantics of the gpio validity checks versus the gpio request mechanism.

gpio_is_valid determines whether a gpio /can/ be attached to a
controller, gpio_request determines whether that gpio currently /is/
attached to a controller.  Part of the confusion seems to come at least
in part from the overlooking of facility for dynamically added gpio
numbers.

Fix the documentation to clarify these points.

[1] http://lkml.org/lkml/2010/8/23/187

Signed-off-by: Ben Nizette <bn@...sdigital.com>
---
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index d96a6db..adc0db2 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -113,12 +113,13 @@ test if a number could reference a GPIO, you may use this predicate:

	int gpio_is_valid(int number);

-A number that's not valid will be rejected by calls which may request
-or free GPIOs (see below).  Other numbers may also be rejected; for
-example, a number might be valid but unused on a given board.
+This will return true for any number which may represent a valid gpio
+regardless of whether or not that identifier is currently active.  To
+determine whether an identifier is linked to a controller and therefore
+able to be used the request/free mechanism should be used (see below).

-Whether a platform supports multiple GPIO controllers is currently a
-platform-specific implementation issue.
+Whether a platform supports multiple and/or dynamically added GPIO
+controllers is currently a platform-specific implementation issue.


Using GPIOs

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ