Messages in this thread | | | From | David Brownell <> | Subject | Re: [patch/rfc 2.6.25-git v2] gpio: sysfs interface | Date | Wed, 30 Apr 2008 19:08:31 -0700 |
| |
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
| |