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.
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.
"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.
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.
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.
You can "cat /sys/kernel/debug/gpio" to see them...
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.
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
--
