Re: [patch 2.6.25-rc5 2/2] gpiochip_reserve()

Previous thread: [patch 2.6.25-rc5 1/2] gpiolib: dynamic gpio number allocation by David Brownell on Thursday, March 13, 2008 - 3:49 pm. (9 messages)

Next thread: [PATCH 0/2] PM: Remove legacy PM by Rafael J. Wysocki on Thursday, March 13, 2008 - 3:51 pm. (8 messages)
From: David Brownell
Date: Thursday, March 13, 2008 - 3:52 pm

From: Anton Vorontsov <avorontsov@ru.mvista.com>

Add a new function gpiochip_reserve() to reserve ranges of gpios that
platform code has pre-allocated.  That is, this marks gpio numbers which
will be claimed by drivers that haven't yet been loaded, and thus are
not available for dynamic gpio number allocation.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 drivers/gpio/gpiolib.c     |   51 ++++++++++++++++++++++++++++++++++++++++++---
 include/asm-generic/gpio.h |    1 
 2 files changed, 49 insertions(+), 3 deletions(-)

--- g26.orig/drivers/gpio/gpiolib.c	2008-03-13 14:51:50.000000000 -0700
+++ g26/drivers/gpio/gpiolib.c	2008-03-13 14:56:16.000000000 -0700
@@ -43,6 +43,7 @@ struct gpio_desc {
 /* flag symbols are bit numbers */
 #define FLAG_REQUESTED	0
 #define FLAG_IS_OUT	1
+#define FLAG_RESERVED	2
 
 #ifdef CONFIG_DEBUG_FS
 	const char		*label;
@@ -88,9 +89,10 @@ static int gpiochip_find_base(int ngpio)
 	int base = -ENOSPC;
 
 	for (i = ARCH_NR_GPIOS - 1; i >= 0 ; i--) {
-		struct gpio_chip *chip = gpio_desc[i].chip;
+		struct gpio_desc *desc = &gpio_desc[i];
+		struct gpio_chip *chip = desc->chip;
 
-		if (!chip) {
+		if (!chip && !test_bit(FLAG_RESERVED, &desc->flags)) {
 			spare++;
 			if (spare == ngpio) {
 				base = i;
@@ -98,7 +100,8 @@ static int gpiochip_find_base(int ngpio)
 			}
 		} else {
 			spare = 0;
-			i -= chip->ngpio - 1;
+			if (chip)
+				i -= chip->ngpio - 1;
 		}
 	}
 
@@ -108,6 +111,48 @@ static int gpiochip_find_base(int ngpio)
 }
 
 /**
+ * gpiochip_reserve() - reserve range of gpios to use with platform code only
+ * @start: starting gpio number
+ * @ngpio: number of gpios to reserve
+ * Context: platform init, potentially before irqs or kmalloc will work
+ *
+ * Returns a negative errno if any gpio within the range is already reserved
+ * or registered, else returns zero as a success code.  Use this function
+ * to mark a range of gpios ...
From: Andrew Morton
Date: Thursday, March 13, 2008 - 4:06 pm

On Thu, 13 Mar 2008 14:52:21 -0800

I applaud the addition of __msut_check to a newly-added function of this
kind, but we usually only add the tag to the declaration, not to the
definition as well.

Not a lot of thought went into this, but we might as well be consistent.

--- a/drivers/gpio/gpiolib.c~gpiochip_reserve-fix
+++ a/drivers/gpio/gpiolib.c
@@ -121,7 +121,7 @@ static int gpiochip_find_base(int ngpio)
  * to mark a range of gpios as unavailable for dynamic gpio number allocation,
  * for example because its driver support is not yet loaded.
  */
-int __init __must_check gpiochip_reserve(int start, int ngpio)
+int __init gpiochip_reserve(int start, int ngpio)
 {
 	int ret = 0;
 	unsigned long flags;


--

From: Dave Jones
Date: Thursday, March 13, 2008 - 6:33 pm

On Thu, Mar 13, 2008 at 04:06:06PM -0700, Andrew Morton wrote:
 > On Thu, 13 Mar 2008 14:52:21 -0800
 > David Brownell <david-b@pacbell.net> wrote:
 > 
 > > +int __init __must_check gpiochip_reserve(int start, int ngpio)
 > 
 > I applaud the addition of __msut_check to a newly-added function of this
 > kind, but we usually only add the tag to the declaration, not to the
 > definition as well.

A bit unfortunate really, given that use of ctags and friends in some editors
jumps to the first definition they come across, so if the prototype is stuffed
somewhere in include/, it shows the definitions from drivers or fs or wherever
that doesn't have the tag.

Given it doesn't cost us anything except a few more bytes in the source code,
is consistency such a bad thing?

	Dave

-- 
http://www.codemonkey.org.uk
--

Previous thread: [patch 2.6.25-rc5 1/2] gpiolib: dynamic gpio number allocation by David Brownell on Thursday, March 13, 2008 - 3:49 pm. (9 messages)

Next thread: [PATCH 0/2] PM: Remove legacy PM by Rafael J. Wysocki on Thursday, March 13, 2008 - 3:51 pm. (8 messages)