Message-Id: <1231504690.8511.8.camel@petitemort>
Date:	Fri, 09 Jan 2009 12:38:10 +0000
From:	Daniel Silverstone <dsilvers@...tec.co.uk>
To:	linux-kernel@...r.kernel.org
Subject: [PATCH] GPIOLIB: Allow GPIOs to be named

Hello,

During recent work for a customer, we needed to export named GPIOs to
userland for them. I investigated various possible ways of doing so, and
eventually reached the conclusion that there were two reasonable ways.
The first required adding the ability to register symbolic links for
classes in sysfs. So that I could have /sys/class/gpio/my-named-gpio be
a symlink to /sys/class/gpio/gpio0 or similar.

However, I felt that would be a touch invasive and so I looked for a
simpler way and decided that simply allowing the gpio_chip struct to
carry an optional names array would be best (and much less invasive).

I was unable to find anything in MAINTAINERS or at the top of gpiolib.c
to indicate who to CC, hence sending this only to the list. Below is a
patch against 2150edc6c5cf00f7adb54538b9ea2a3e9cedca3f.

I'd appreciate comments and ideas for how to do this better, or if it is
acceptable, I'd love to see it merged.

Regards,

Daniel.

--- Cut ---

GPIOLIB: Allow GPIOs to be named

This patch allows GPIOs in GPIOLIB chips to be named. This name is
then used when the GPIO is exported to sysfs, although it could be
used elsewhere if deemed useful.

Signed-off-by: Daniel Silverstone <dsilvers@...tec.co.uk>

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 35e7aea..de2f114 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -438,6 +438,7 @@ int gpio_export(unsigned gpio, bool direction_may_change)
 	unsigned long		flags;
 	struct gpio_desc	*desc;
 	int			status = -EINVAL;
+	char			*ioname = NULL;
 
 	/* can't export until sysfs is available ... */
 	if (!gpio_class.p) {
@@ -461,11 +462,14 @@ int gpio_export(unsigned gpio, bool direction_may_change)
 	}
 	spin_unlock_irqrestore(&gpio_lock, flags);
 
+	if (desc->chip->names && desc->chip->names[gpio - desc->chip->base])
+		ioname = desc->chip->names[gpio - desc->chip->base];
+
 	if (status == 0) {
 		struct device	*dev;
 
 		dev = device_create(&gpio_class, desc->chip->dev, MKDEV(0, 0),
-					desc, "gpio%d", gpio);
+				    desc, ioname ? ioname : "gpio%d", gpio);
 		if (dev) {
 			if (direction_may_change)
 				status = sysfs_create_group(&dev->kobj,
@@ -513,6 +517,7 @@ void gpio_unexport(unsigned gpio)
 	mutex_lock(&sysfs_lock);
 
 	desc = &gpio_desc[gpio];
+
 	if (test_bit(FLAG_EXPORT, &desc->flags)) {
 		struct device	*dev = NULL;
 
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 81797ec..d6c379d 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -55,6 +55,10 @@ struct module;
  *	handled is (base + ngpio - 1).
  * @can_sleep: flag must be set iff get()/set() methods sleep, as they
  *	must while accessing GPIO expander chips over I2C or SPI
+ * @names: if set, must be an array of strings to use as alternative
+ *      names for the GPIOs in this chip. Any entry in the array
+ *      may be NULL if there is no alias for the GPIO, however the
+ *      array must be @ngpio entries long.
  *
  * A gpio_chip can help platforms abstract various sources of GPIOs so
  * they can all be accessed through a common programing interface.
@@ -92,6 +96,7 @@ struct gpio_chip {
 						struct gpio_chip *chip);
 	int			base;
 	u16			ngpio;
+	char			**names;
 	unsigned		can_sleep:1;
 	unsigned		exported:1;
 };


-- 
Daniel Silverstone                              http://www.simtec.co.uk/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895


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