[PATCH] GPIOLIB: Allow GPIOs to be named

[PATCH] GPIOLIB: Allow GPIOs to be named

[Daniel Silverstone]

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@simtec.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

Re: [PATCH] GPIOLIB: Allow GPIOs to be named

[Andrew Morton]

On Fri, 09 Jan 2009 12:38:10 +0000
Daniel Silverstone <dsilvers@simtec.co.uk> wrote:

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

gpio core is developed/maintained by David Brownell.  Who owes us a
MAINTAINERS update ;)

> I'd appreciate comments and ideas for how to do this better, or if it is
> acceptable, I'd love to see it merged.
> 
> ...
>
> 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@simtec.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;
>  };
> 

Well it's nice and simple.

Re: [PATCH] GPIOLIB: Allow GPIOs to be named

[Daniel Silverstone]

On Tue, 2009-01-13 at 13:14 -0800, Andrew Morton wrote:
> > 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.
> gpio core is developed/maintained by David Brownell.  Who owes us a
> MAINTAINERS update ;)

David, have you had a chance to review this patch? It was also
added-to-mm on the 13th Jan as gpiolib-allow-gpios-to-be-named.patch --
I believe you were CCed on this add.

With -rc8 looming, I am anxious to know if this is acceptable for going
into the .30 merge window.

Regards,

Daniel.

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

Re: [PATCH] GPIOLIB: Allow GPIOs to be named

[Daniel Silverstone]

On Thu, 2009-03-05 at 12:27 +0000, Daniel Silverstone wrote:
> > > 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.
> > gpio core is developed/maintained by David Brownell.  Who owes us a
> > MAINTAINERS update ;)
> David, have you had a chance to review this patch? It was also
> added-to-mm on the 13th Jan as gpiolib-allow-gpios-to-be-named.patch --
> I believe you were CCed on this add.
> With -rc8 looming, I am anxious to know if this is acceptable for going
> into the .30 merge window.

Andrew,

with -rc8 out, and David apparently MIA on this topic, is now an
appropriate time for me to ask that you queue this up for the .30 merge
window, or is that something you can't really do?

Regards,

Daniel.

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

Re: [PATCH] GPIOLIB: Allow GPIOs to be named

[Daniel Silverstone]

On Fri, 2009-03-13 at 09:43 +0000, Daniel Silverstone wrote:
> > David, have you had a chance to review this patch? It was also
> > added-to-mm on the 13th Jan as gpiolib-allow-gpios-to-be-named.patch --
> > I believe you were CCed on this add.
> > With -rc8 looming, I am anxious to know if this is acceptable for going
> > into the .30 merge window.
> Andrew,
> with -rc8 out, and David apparently MIA on this topic, is now an
> appropriate time for me to ask that you queue this up for the .30 merge
> window, or is that something you can't really do?

While I hate to nag, I thought I should ping on this again. Any movement
on whether or not this will go in?

Regards,

Daniel.

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