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);
next prev 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.