From: Ben Nizette <bn@niasdigital.com>
To: David Brownell <david-b@pacbell.net>
Cc: lkml <linux-kernel@vger.kernel.org>,
Trent Piepho <tpiepho@freescale.com>,
hartleys <hartleys@visionengravers.com>,
Mike Frysinger <vapier.adi@gmail.com>,
Bryan Wu <cooloney@kernel.org>
Subject: Re: [patch/rfc 2.6.25-git v2] gpio: sysfs interface
Date: Thu, 01 May 2008 09:28:13 +1000 [thread overview]
Message-ID: <1209598093.3377.30.camel@moss.renham> (raw)
In-Reply-To: <200804301434.25211.david-b@pacbell.net>
On Wed, 2008-04-30 at 14:34 -0700, David Brownell wrote:
> Simple sysfs interface for GPIOs.
>
> /sys/class/gpio
> /control ... to request a GPIO be imported or returned
> /gpioN ... for each exported GPIO #N
> /value ... always readable, writes fail for input GPIOs
> /direction ... r/w as: in, out (default low); write high, low
> /gpiochipN ... for each gpiochip; #N is its first GPIO
> /base ... (r/o) same as N
> /label ... (r/o) descriptive, not necessarily unique
> /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)
You dropped the 'device' symlink? Sure it won't always be available but
I did quite like the idea of being able to walk back through sysfs and
discover, for example, the SPI chip select to which it's attached.
>
> GPIOs may be exported by kernel code using gpio_export(), which should
> be most useful for driver debugging. Userspace may also ask that they
> be imported by writing to the sysfs control file, helping to cope with
> incomplete board support:
>
> echo "23" > /sys/class/gpio/control
> ... will gpio_request(23, "sysfs") and gpio_export(23); use
> /sys/class/gpio/gpio-23/direction to configure it.
> echo "-23" > /sys/class/gpio/control
> ... will gpio_free(23)
>
> The extra D-space footprint is a few hundred bytes, except for the sysfs
> resources associated with each exported GPIO. The additional I-space
> footprint is about two thirds of the current size of gpiolib (!). Since
> no /dev node creation is involved, no "udev" support is needed.
>
> This adds a device pointer to "struct gpio_chip". When GPIO providers
> initialize that, sysfs gpio class devices become children of that device
> instead of being "virtual" devices. The (few) gpio_chip providers which
> have such a device node have been updated. (Some also needed to update
> their module "owner" field ... for which missing kerneldoc was added.)
>
> Based on a patch from Trent Piepho <tpiepho@freescale.com>, and comments
> from various folk including most recently Hartley Sweeten and Ben Nizette.
>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> ---
> Notable updates from previous version: doc update, mutex protection
> for sysfs access, export basic gpio_chip info ("what GPIOs exist"),
> depend on new sysfs_streq() call, simplified control file syntax.
>
[...]
> +
> +/*
> + * /sys/class/gpio/control ... write-only
> + * integer N: non-negative == export; negative == unexport
> + */
> +static ssize_t control_store(struct class *class, const char *buf, size_t len)
> +{
> + long gpio;
> + int status;
> +
> + status = strict_strtol(buf, 0, &gpio);
> + if (status < 0)
> + goto done;
> +
> + /* No extra locking here; FLAG_SYSFS just signifies that the
> + * request and export were done by on behalf of userspace, so
> + * they may be undone on its behalf too.
> + */
> +
> + if (gpio >= 0) { /* export */
> + status = gpio_request(gpio, "sysfs");
> + if (status < 0)
> + goto done;
> +
> + status = gpio_export(gpio);
> + if (status < 0)
> + gpio_free(gpio);
> + else
> + set_bit(FLAG_SYSFS, &gpio_desc[gpio].flags);
> +
> + } else { /* unexport */
Unexport gpio 0?
> + gpio = -gpio;
> +
> + /* reject bogus commands (gpio_unexport ignores them) */
> + if (!gpio_is_valid(gpio))
> + goto fail;
> + if (!test_and_clear_bit(FLAG_SYSFS, &gpio_desc[gpio].flags))
> + goto fail;
> + status = 0;
> + gpio_free(gpio);
> + }
> +done:
> + if (status)
> + pr_debug("%s: status %d\n", __func__, status);
> + return status ? : len;
> +fail:
> + pr_debug("%s: fail\n", __func__);
> + return -EINVAL;
> +}
> +
next prev parent reply other threads:[~2008-04-30 23:28 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 19:39 [patch/rfc 2.6.25-git] gpio: sysfs interface David Brownell
2008-04-28 20:46 ` Andrew Morton
2008-04-28 23:28 ` David Brownell
2008-04-29 2:54 ` Andrew Morton
2008-04-29 3:42 ` Greg KH
2008-04-29 18:45 ` David Brownell
2008-04-29 19:09 ` Andrew Morton
2008-05-02 20:36 ` Pavel Machek
2008-05-17 22:14 ` David Brownell
2008-05-18 0:36 ` [patch 2.6.26-rc2-git] " David Brownell
2008-05-20 7:17 ` Andrew Morton
2008-05-18 4:55 ` [patch/rfc 2.6.25-git] " Ben Nizette
2008-05-19 22:39 ` Pavel Machek
2008-05-20 1:26 ` David Brownell
2008-05-20 8:02 ` Pavel Machek
2008-04-28 23:01 ` Ben Nizette
2008-04-29 0:44 ` David Brownell
2008-04-29 1:58 ` Ben Nizette
2008-04-29 3:44 ` David Brownell
2008-04-29 4:47 ` Ben Nizette
2008-04-29 21:28 ` David Brownell
2008-04-29 6:17 ` Trent Piepho
2008-04-29 22:39 ` David Brownell
2008-04-28 23:09 ` Trent Piepho
2008-04-29 0:45 ` David Brownell
2008-04-29 5:48 ` Trent Piepho
2008-04-29 12:35 ` Ben Nizette
2008-04-29 18:15 ` Trent Piepho
2008-04-29 21:56 ` David Brownell
2008-04-30 0:49 ` Trent Piepho
2008-04-30 17:49 ` David Brownell
2008-04-29 21:55 ` David Brownell
2008-04-29 23:29 ` Ben Nizette
2008-04-30 1:04 ` David Brownell
2008-04-30 2:08 ` Ben Nizette
2008-04-30 3:13 ` Trent Piepho
2008-04-30 10:33 ` Ben Nizette
2008-04-30 17:42 ` David Brownell
2008-04-30 21:34 ` [patch/rfc 2.6.25-git v2] " David Brownell
2008-04-30 22:47 ` Trent Piepho
2008-04-30 23:14 ` Ben Nizette
2008-05-01 2:12 ` David Brownell
2008-05-01 2:08 ` David Brownell
2008-05-01 3:41 ` Trent Piepho
2008-05-01 4:35 ` David Brownell
2008-05-01 21:16 ` Trent Piepho
2008-05-03 2:58 ` David Brownell
2008-05-03 3:05 ` David Brownell
2008-04-30 23:28 ` Ben Nizette [this message]
2008-05-01 21:40 ` David Brownell
2008-04-29 0:47 ` [patch/rfc 2.6.25-git] " Ben Nizette
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=1209598093.3377.30.camel@moss.renham \
--to=bn@niasdigital.com \
--cc=cooloney@kernel.org \
--cc=david-b@pacbell.net \
--cc=hartleys@visionengravers.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tpiepho@freescale.com \
--cc=vapier.adi@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox