linux-kernel - Re: [patch/rfc 2.6.25-git v2] gpio: sysfs interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0804301511120.1537@t2.domain.actdsltmp>
Date:	Wed, 30 Apr 2008 15:47:50 -0700 (PDT)
From:	Trent Piepho <tpiepho@...escale.com>
To:	David Brownell <david-b@...bell.net>
cc:	lkml <linux-kernel@...r.kernel.org>,
	Ben Nizette <bn@...sdigital.com>,
	Trent Piepho <tpiepho@...escale.com>,
	hartleys <hartleys@...ionengravers.com>,
	Mike Frysinger <vapier.adi@...il.com>,
	Bryan Wu <cooloney@...nel.org>
Subject: Re: [patch/rfc 2.6.25-git v2] gpio: sysfs interface

On Wed, 30 Apr 2008, 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)

"simple"?  What I had was a lot simpler.

So, I want to set gpio 5 on a pcf9557 extender.

cat 1 > /sys/class/gpio/pcf9557-0:0

But now I can't do this anymore, it has to be harder.  So how do I do it?  It
doesn't seem very considerate to ignore the real use cases of the person who
wrote the code to begin with.

> GPIOs may be exported by kernel code using gpio_export(), which should
> be most useful for driver debugging.  Userspace may also ask that they

I have a JTAG interface implemented via GPIOs.  With my system, one can see
the gpios used in sysfs with the proper labels (TCK, TDO, TDI, etc.).  This is
very helpful for people connecting something to the interface to know they
have the write gpio lines connected.  What's the point of allowing
one to label gpio lines if it's not going to be easy to see?

It also means that if they have trouble getting what their connecting to work,
they can always control the line via sysfs and see with a probe that it
changes.  They can raise TRST (which they know is the right line from the
label) and see the system reset.

Adding gpio_export() calls to the kernel source and recompiling and
re-flashing just isn't going to happen for a large portion of users.

Why can't the gpio lines just show up when something requests them?

> 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

So if a driver is already using gpio 23, then there is no way to see it in
sysfs, since the gpio_request() will fail?

> 	/sys/class/gpio/gpio-23/direction to configure it.
>  echo "-23" > /sys/class/gpio/control
> 	... will gpio_free(23)

So if a driver was already using gpio 23 and you wanted to look at it from
userspace, you'll free it from both sysfs and the driver that was using it
when you're done?

> +When a kernel driver has requested a GPIO, it may only be made available
> +in the sysfs interface by gpio_export().  This prevents userspace code
> +from clobbering important state.

You could say the same about 90% of the writable files in sysfs.
--
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/