Message-Id: <1209423678.14631.27.camel@moss.renham>
Date:	Tue, 29 Apr 2008 09:01:18 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	David Brownell <david-b@...bell.net>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Trent Piepho <tpiepho@...escale.com>,
	hartleys <hartleys@...ionengravers.com>,
	Mike Frysinger <vapier.adi@...il.com>,
	Bryan Wu <cooloney@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch/rfc 2.6.25-git] gpio: sysfs interface


On Mon, 2008-04-28 at 12:39 -0700, David Brownell wrote:
> Simple sysfs interface for GPIOs.
> 
>     /sys/class/gpio
>         /gpio-N ... for each exported GPIO #N
> 	    /value ... always readable, writes fail except for output GPIOs
> 	    /direction ... writable as: in, out (default low), high, low
>     	/control ... to request a GPIO be exported or unexported
> 
> 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 exported by writing to the sysfs control file, helping to cope with
> incomplete board support:
> 
>   echo "export 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 "unexport 23" > /sys/class/gpio/control
> 	... will gpio_free(23)

Righteo, so if the kernel explicitly gpio_export()s something, it won't
be gpio_request()ed allowing multiple "owners" making driver debugging
easier.  Most of the time though we don't want to be able to clobber the
kernel's gpios so the control file wizardry isn't so much to cope with
incomplete board support, rather it's the way all regular (ie
non-driver-debugging) gpio access is started..?  Or do you class any
situation where userspace needs primary gpio control as a BSP omission
as there Should Be a formal in-kernel driver for it all?

Also, gpio number discovery can be done through the debugfs interface
already in gpiolib but once you've got a userspace gpio interface which
relies on gpio numbering like this that information ceases to be simple
debugging and becomes pretty mission-critical.  IMO it would make more
sense to shuffle it in to /sys/class/gpio with all this stuff or at
least offer a cut-down chip-to-range mapping in a file here.

> 
> The D-space footprint is negligible, except for the sysfs resources
> associated with each exported GPIO.  The additional I-space footprint
> is about half of the current size of gpiolib.  No /dev node creation
> involved, and no "udev" support is needed.

Which is good for simplicity but makes async notification kinda tricky.
I would suggest that a lack of pin-change signalling is going to be a
problem for people who've become accustomed to having it in their
out-of-tree interfaces.  Probably not a showstopper here but certainly
something which will slow the uptake of this interface.

> 
> 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@...escale.com>, and comments
> from various folk including Hartley Sweeten.
> 
> Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>

[had some comments regarding the code but it seems akpm covered them all
already :-)]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists