Thread (24 messages) 24 messages, 3 authors, 2012-10-22

[PATCH RFC 02/15 v5] gpio: Add sysfs support to block GPIO API

From: Roland Stigge <hidden>
Date: 2012-10-19 11:51:17
Also in: lkml

On 10/19/2012 12:35 PM, Linus Walleij wrote:
On Thu, Oct 18, 2012 at 12:07 PM, Roland Stigge [off-list ref] wrote:
quoted
On 10/17/2012 09:05 PM, Greg KH wrote:
quoted
quoted
+    if (value != exported) {
+            if (value)
+                    status = gpio_block_value_export(block);
+            else
+                    status = gpio_block_value_unexport(block);
That looks like a recipie for disaster.  Why do you allow userspace to
do this?
Exporting for gpio blocks is done as follows: writing "1" to the
"exported" _device_ attribute of the gpio block creates the "values"
attribute and at the same time requests the whole block (including all
of its gpios) as "sysfs".
To me it reads like Greg's comment is basically pinpointing a flaw
in Brownell's initial design of gpio sysfs: that new sysfs files are
created and destroyed by writing into sysfs */export files from
userspace?

See commit: d8f388d8dc8d4f36539dd37c1fff62cc404ea0fc

The block GPIO stuff is just following that design pattern.
So what do you think about my just proposed idea of always having the
"value" argument present, but only useable when "exported" is "1"? Now
only talking about the block gpios, but later maybe also for gpios?

But I would only do this if you and Greg consider it reasonable.

Thanks in advance,

Roland
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help