RE: [PATCH] gpio/gpio-sysfs: Try to export busy GPIO line leads towrong GPIO line exporting

[Stephen Warren]

Denis Kuzmenko wrote at Saturday, November 12, 2011 6:31 PM:
> From: Denis Kuzmenko <linux@xxxxxxxxxxxxxx>
> 
> Fix bug in gpio-sysfs interface (export of busy GPIO line leads to export of different GPIO line).
> 
> Signed-off-by: Denis Kuzmenko <linux@xxxxxxxxxxxxxx>
> ---
> 
> Patch is against 3.0.9
> When trying to export GPIO line 37(40) which is already exported/requested by kernel code we got GPIO
> line 3(4) exported.
> Looks like this is done because `export_store` function doesn't return the number of processed bytes
> and gets a part of previous buffer again.
> This fix works for me (Samsung s3c2440).
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a971e3d..ccec497 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -633,7 +633,7 @@ static ssize_t export_store(struct class *class,
>  done:
>  	if (status)
>  		pr_debug("%s: status %d\n", __func__, status);
> -	return status ? : len;
> +	return len;
>  }

I assume that when the error occurs, status is negative. Is it some
special value like EINTR, EAGAIN? I'm surprised that the retried write
is smaller than the whole original buffer.

What's actually retrying the failed write? Is it user-space in response
to the previous failed write, in a (mistaken?) attempt to handle shorter-
than-expected-writes? You could confirm this with strace.

If the patch above really is correct, there are other places it'd be
needed; it looks like e.g. drivers/video/backlight/backlight.c would
have the same issue if you gave too-large integers to its sysfs files.

-- 
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/