All of lore.kernel.org
 help / color / mirror / Atom feed
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;
> +}
> +

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