All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Cc: Tzachi Perelstein <tzachi@marvell.com>
Subject: [patch 2.6.24-rc4-mm 2/6] gpiolib: more CONFIG_DEBUG_GPIO diagnostics
Date: Sun, 9 Dec 2007 20:39:38 -0800	[thread overview]
Message-ID: <200712092039.38917.david-b@pacbell.net> (raw)
In-Reply-To: <200712092022.14062.david-b@pacbell.net>

From: David Brownell <dbrownell@users.sourceforge.net>

Update gpiolib behavior with CONFIG_DEBUG_GPIO to include messages
on some fault paths that are common during bringup:  gpiochip_add,
gpio_request, and the two gpio_direction_* calls.

Also morph that CONFIG symbol into compile-time -DDEBUG.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Tzachi Perelstein <tzachi@marvell.com>
---
 lib/Kconfig.debug |   10 ++++++----
 lib/Makefile      |    4 ++++
 lib/gpiolib.c     |   33 ++++++++++++++++++++++++++++-----
 3 files changed, 38 insertions(+), 9 deletions(-)

--- a/lib/Kconfig.debug	2007-12-09 19:50:50.000000000 -0800
+++ b/lib/Kconfig.debug	2007-12-09 19:51:02.000000000 -0800
@@ -160,10 +160,12 @@ config DEBUG_GPIO
 	bool "Debug GPIO calls"
 	depends on DEBUG_KERNEL && GPIO_LIB
 	help
-	  Say Y here to add some extra checks to GPIO calls, ensuring that
-	  GPIOs have been properly initialized before they are used and
-	  that sleeping calls aren't made from nonsleeping contexts.  This
-	  can make bitbanged serial protocols slower.
+	  Say Y here to add some extra checks and diagnostics to GPIO calls.
+	  The checks help ensure that GPIOs have been properly initialized
+	  before they are used and that sleeping calls aren't made from
+	  nonsleeping contexts.  They can make bitbanged serial protocols
+	  slower.  The diagnostics help catch the type of setup errors
+	  that are most common when setting up new platforms or boards.
 
 config DEBUG_SLAB_LEAK
 	bool "Memory leak debugging"
--- a/lib/Makefile	2007-12-09 19:50:50.000000000 -0800
+++ b/lib/Makefile	2007-12-09 19:51:02.000000000 -0800
@@ -68,6 +68,10 @@ obj-$(CONFIG_FAULT_INJECTION) += fault-i
 
 lib-$(CONFIG_GENERIC_BUG) += bug.o
 
+ifeq ($(CONFIG_DEBUG_GPIO),y)
+CFLAGS_gpiolib.o += -DDEBUG
+endif
+
 lib-$(CONFIG_GPIO_LIB) += gpiolib.o
 
 hostprogs-y	:= gen_crc32table
--- a/lib/gpiolib.c	2007-12-09 19:50:59.000000000 -0800
+++ b/lib/gpiolib.c	2007-12-09 19:51:02.000000000 -0800
@@ -20,9 +20,12 @@
 
 
 /* When debugging, extend minimal trust to callers and platform code.
+ * Also emit diagnostic messages that may help initial bringup, when
+ * board setup or driver bugs are most common.
+ *
  * Otherwise, minimize overhead in what may be bitbanging codepaths.
  */
-#ifdef	CONFIG_DEBUG_GPIO
+#ifdef	DEBUG
 #define	extra_checks	1
 #else
 #define	extra_checks	0
@@ -48,8 +51,11 @@ struct gpio_desc {
 static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
 
 
-/* Warn when drivers omit gpio_request() calls -- legal but
- * ill-advised when setting direction, and otherwise illegal.
+/* Warn when drivers omit gpio_request() calls -- legal but ill-advised
+ * when setting direction, and otherwise illegal.  Until board setup code
+ * and drivers use explicit requests everywhere (which won't happen when
+ * those calls have no teeth) we can't avoid autorequesting.  This nag
+ * message should motivate switching to explicit requests...
  */
 static void gpio_ensure_requested(struct gpio_desc *desc)
 {
@@ -86,8 +92,10 @@ int gpiochip_add(struct gpio_chip *chip)
 	 * dynamic allocation.  We don't currently support that.
 	 */
 
-	if (chip->base < 0 || (chip->base  + chip->ngpio) >= ARCH_NR_GPIOS)
-		return -EINVAL;
+	if (chip->base < 0 || (chip->base  + chip->ngpio) >= ARCH_NR_GPIOS) {
+		status = -EINVAL;
+		goto fail;
+	}
 
 	spin_lock_irqsave(&gpio_lock, flags);
 
@@ -106,6 +114,12 @@ int gpiochip_add(struct gpio_chip *chip)
 	}
 
 	spin_unlock_irqrestore(&gpio_lock, flags);
+fail:
+	/* failures here can mean systems won't boot... */
+	if (status)
+		pr_err("gpiochip_add: gpios %d..%d (%s) not registered\n",
+			chip->base, chip->base + chip->ngpio,
+			chip->label ? : "generic");
 	return status;
 }
 EXPORT_SYMBOL_GPL(gpiochip_add);
@@ -172,6 +186,9 @@ int gpio_request(unsigned gpio, const ch
 		status = -EBUSY;
 
 done:
+	if (status)
+		pr_debug("gpio_request: gpio-%d (%s) status %d\n",
+			gpio, label ? : "?", status);
 	spin_unlock_irqrestore(&gpio_lock, flags);
 	return status;
 }
@@ -272,6 +289,9 @@ int gpio_direction_input(unsigned gpio)
 	return status;
 fail:
 	spin_unlock_irqrestore(&gpio_lock, flags);
+	if (status)
+		pr_debug("%s: gpio-%d status %d\n",
+			__FUNCTION__, gpio, status);
 	return status;
 }
 EXPORT_SYMBOL_GPL(gpio_direction_input);
@@ -307,6 +327,9 @@ int gpio_direction_output(unsigned gpio,
 	return status;
 fail:
 	spin_unlock_irqrestore(&gpio_lock, flags);
+	if (status)
+		pr_debug("%s: gpio-%d status %d\n",
+			__FUNCTION__, gpio, status);
 	return status;
 }
 EXPORT_SYMBOL_GPL(gpio_direction_output);

  parent reply	other threads:[~2007-12-10  4:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200712092022.14062.david-b@pacbell.net>
2007-12-10  4:39 ` [patch 2.6.24-rc4-mm 1/6] gpiolib: add gpio_desc[] David Brownell
2007-12-10  4:39 ` David Brownell [this message]
2007-12-10  4:39 ` [patch 2.6.24-rc4-mm 3/6] gpiolib: implementor-oriented documentation David Brownell
2007-12-10  4:39 ` [patch 2.6.24-rc4-mm 4/6] gpiolib: create empty drivers/gpio David Brownell
2007-12-10 16:16   ` Jean Delvare
2007-12-10 16:52     ` David Brownell
2007-12-10  4:40 ` [patch 2.6.24-rc4-mm 5/6] gpiolib: pcf857x i2c expander driver David Brownell
2007-12-10  4:40 ` [patch 2.6.24-rc4-mm 6/6] gpiolib: replacement mcp23s08 driver David Brownell

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=200712092039.38917.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tzachi@marvell.com \
    /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.