From: Andrew Morton <akpm@linux-foundation.org>
To: dsilvers@simtec.co.uk
Cc: linux-kernel@vger.kernel.org, David Brownell <david-b@pacbell.net>
Subject: Re: [PATCH] GPIOLIB: Allow GPIOs to be named
Date: Tue, 13 Jan 2009 13:14:17 -0800 [thread overview]
Message-ID: <20090113131417.fe36d9bb.akpm@linux-foundation.org> (raw)
In-Reply-To: <1231504690.8511.8.camel@petitemort>
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.
next prev parent reply other threads:[~2009-01-13 21:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-09 12:38 [PATCH] GPIOLIB: Allow GPIOs to be named Daniel Silverstone
2009-01-13 21:14 ` Andrew Morton [this message]
2009-03-05 12:27 ` Daniel Silverstone
2009-03-13 9:43 ` Daniel Silverstone
2009-03-25 14:08 ` Daniel Silverstone
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=20090113131417.fe36d9bb.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=dsilvers@simtec.co.uk \
--cc=linux-kernel@vger.kernel.org \
/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.