lkml.org 
[lkml]   [2009]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH] GPIOLIB: Allow GPIOs to be named
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.


\
 
 \ /
  Last update: 2009-01-13 22:17    [W:2.057 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site