Skip to contentSkip to conversation

gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios

PATCH In review Mathias Nyman 3 participants 3 messages Oct 25, 2012 – Oct 27, 2012 GPIO

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios

gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure.

---
 drivers/gpio/gpiolib.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)
drivers/gpio/gpiolib.c +7 -3
index 141f793..b59d240 100644
@@ -651,9 +651,11 @@ static ssize_t export_store(struct class *class,
 	 */
 
 	status = gpio_request(gpio, "sysfs");
-	if (status < 0)
+	if (status < 0) {
+		if (status == -EPROBE_DEFER)
+			status = -ENODEV;
 		goto done;
-
+	}
 	status = gpio_export(gpio, true);
 	if (status < 0)
 		gpio_free(gpio);
@@ -1220,8 +1222,10 @@ int gpio_request(unsigned gpio, const char *label)
 
 	spin_lock_irqsave(&gpio_lock, flags);
 
-	if (!gpio_is_valid(gpio))
+	if (!gpio_is_valid(gpio)) {
+		status = -EINVAL;
 		goto done;
+	}
 	desc = &gpio_desc[gpio];
 	chip = desc->chip;
 	if (chip == NULL)
Signature · 1 line
1.7.4.1
#1 lore raw
Quoted 4 lines · Mathias Nyman

gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure.

Very good catch. I applied this to my fixes branch and also put the stable tag on this thing, it goes way back to the introduction of deffered probe.

Mark: OK with this?

Yours,
Linus Walleij

#2 lore raw
Quoted 10 lines · Linus Walleij

On Thu, Oct 25, 2012 at 1:03 PM, Mathias Nyman

Quoted 2 lines

gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure.

Very good catch. I applied this to my fixes branch and also put the stable tag on this thing, it goes way back to the introduction of deffered probe.

Mark: OK with this?

The invalid numbers thing I'm a bit meh on. It came up before and I personally wasn't sure if the issue wasn't with gpio_is_valid() only checking for "this number could possibly ever be a GPIO" and not doing any checking against the GPIOs that have actually been registered. If it's the former then ideally at some point in the future we'll remove the big table and gpio_is_valid() will always be true.