Message-Id: <200804301908.32346.david-b@pacbell.net>
Date:	Wed, 30 Apr 2008 19:08:31 -0700
From:	David Brownell <david-b@...bell.net>
To:	Trent Piepho <tpiepho@...escale.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Ben Nizette <bn@...sdigital.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 Wednesday 30 April 2008, Trent Piepho wrote:
> On Wed, 30 Apr 2008, David Brownell wrote:
> > Simple sysfs interface for GPIOs.
> >
> >    /sys/class/gpio
> >    	...
> 
> "simple"?  What I had was a lot simpler.

But it had some "must fix" problems, which I told you when you
posted your first patch.  You didn't fix them.  And since then,
your pushback seems to rely very heavily on ignoring issues I
pointed out are "must fix" or "can't/doesn't work that way".

It's easy to be simple if you don't have to be correct or safe.


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

Which isn't exactly where most folk start.  If it's something
done routinely, they'll likely have a script to run; either
the native language type, or something for bash or Python.

If it's a one-off, they probably start from schematics and
are fully capable of adding 5 to the base number associated
with the particular pcf chip in question (say, the third one
on this card stack) ... and doing the same for other pins
they need to diddle.  Note taking is always a good practice
when sorting out such issues, but adding five is in your head
is far from rocket science.


> cat 1 > /sys/class/gpio/pcf9557-0:0
> 
> But now I can't do this anymore,

"Any more"?  You never *could* do that before.  The original
patch you sent didn't do that, and the last code snippet I
saw from you didn't either.


> it has to be harder.  So how do I do it?  It 
> doesn't seem very considerate to ignore the real use cases

I didn't ignore *use cases* at all.  You can certainly set
the value of such a GPIO with the $SUBJECT interface.

Just ... not using that syntax.  Use cases are several steps
above solution details, such as a particular syntax.


> of the person who wrote the code to begin with.

I've seen at least half a dozen different userspace models for
how to work with GPIOs.  You didn't write all of them.  Nor
were yours the only use cases.


> 	 What's the point of allowing
> one to label gpio lines if it's not going to be easy to see?

You can "cat /sys/kernel/debug/gpio" to see them...


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

Right.  If that driver wanted to cope with userspace mucking
around with its internal state (GPIOs) it would have explicitly
enabled it by calling gpio_export().  If it's not prepared to
cope with the various flavors of breakage that would facilitate,
it doesn't call gpio_export() ... and is safe.


> > 	/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?

No, that was the one-line summary.  It's only freed if it was
originally requested from userspace (by "echo 23 > control").
As you can see in the code...

- Dave


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