Skip to contentSkip to conversation

gpio: remove spurious gpio_unexport debug error.

PATCH In review Gregory Bean 3 participants 4 messages Jul 22, 2010 – Jul 27, 2010

Subsystems (2)
Arm Qualcomm mailing list GPIO
lore
Share & tools
lore

Gregory Bean

author
#0 lore raw

PATCH 1/1 gpio: remove spurious gpio_unexport debug error.

Make gpio_unexport generate success instead of an -EINVAL if asked to unexport a line which is not exported, because the only result of that condition is a pr_debug which complains of what is really a harmless no-op:
when an unexported gpio is unexported again, nothing happens. That's not a failure, just a trivial border case. Since gpio_free calls gpio_unexport unconditionally and exported gpio lines are uncommon, most calls to gpio_free with debug flags enabled generate -EINVAL warnings in the log, causing unnecessary stress.

Signed-off-by Gregory Bean <[email protected]>
---
 drivers/gpio/gpiolib.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
drivers/gpio/gpiolib.c +2 -1
index 3ca3654..b718aea 100644
@@ -914,7 +914,8 @@ void gpio_unexport(unsigned gpio)
 			status = 0;
 		} else
 			status = -ENODEV;
-	}
+	} else
+		status = 0;
 
 	mutex_unlock(&sysfs_lock);
 done:
Signature · 5 lines
1.7.0.4

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
Acked-by on v1 1/1
#1 lore raw

Hello,

Quoted 10 lines · Gregory Bean

Make gpio_unexport generate success instead of an -EINVAL if asked to unexport a line which is not exported, because the only result of that condition is a pr_debug which complains of what is really a harmless no-op:
when an unexported gpio is unexported again, nothing happens. That's not a failure, just a trivial border case. Since gpio_free calls gpio_unexport unconditionally and exported gpio lines are uncommon, most calls to gpio_free with debug flags enabled generate -EINVAL warnings in the log, causing unnecessary stress.

I noticed that a few days ago, too. Just didn't come around to fix it myself.

Quoted 1 line
Signed-off-by Gregory Bean <[email protected]>
Acked-by Uwe Kleine-K?nig <[email protected]>

Thanks
Uwe

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
#2 lore raw
Quoted 13 lines · On Fri, 23 Jul 2010 06:58:07 +0200 Uwe Kleine-K__nig…

Hello,

Quoted 10 lines · Gregory Bean

Make gpio_unexport generate success instead of an -EINVAL if asked to unexport a line which is not exported, because the only result of that condition is a pr_debug which complains of what is really a harmless no-op:
when an unexported gpio is unexported again, nothing happens. That's not a failure, just a trivial border case. Since gpio_free calls gpio_unexport unconditionally and exported gpio lines are uncommon, most calls to gpio_free with debug flags enabled generate -EINVAL warnings in the log, causing unnecessary stress.

Quoted 6 lines

I noticed that a few days ago, too. Just didn't come around to fix it myself.

Quoted 1 line
Signed-off-by Gregory Bean <[email protected]>
Acked-by Uwe Kleine-K__nig <[email protected]>

Jon got there first ;)

Subject: gpio: fix spurious printk when freeing a gpio

From: Jon Povey <[email protected]>

When freeing a gpio that has not been exported, gpio_unexport() prints a debug message when it should just fall through silently.

Example spurious message:

gpio_unexport: gpio0 status -22

Signed-off-by Jon Povey <[email protected]>
Cc David Brownell <[email protected]>
Signed-off-by Andrew Morton <[email protected]>

---

 drivers/gpio/gpiolib.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpio/gpiolib.c renamed from drivers/gpio/gpiolib.c~gpio-fix-spurious-printk-when-freeing-a-gpio +4 -3
diff -puN drivers/gpio/gpiolib.c~gpio-fix-spurious-printk-when-freeing-a-gpio drivers/gpio/gpiolib.c
@@ -893,10 +893,12 @@ EXPORT_SYMBOL_GPL(gpio_sysfs_set_active_
 void gpio_unexport(unsigned gpio)
 {
 	struct gpio_desc	*desc;
-	int			status = -EINVAL;
+	int			status = 0;
 
-	if (!gpio_is_valid(gpio))
+	if (!gpio_is_valid(gpio)) {
+		status = -EINVAL;
 		goto done;
+	}
 
 	mutex_lock(&sysfs_lock);
 

@@ -911,7 +913,6 @@ void gpio_unexport(unsigned gpio)
 			clear_bit(FLAG_EXPORT, &desc->flags);
 			put_device(dev);
 			device_unregister(dev);
-			status = 0;
 		} else
 			status = -ENODEV;
 	}

_

#3 lore raw

Hello Andrew,

Quoted 16 lines · Andrew Morton
Quoted 13 lines · On Fri, 23 Jul 2010 06:58:07 +0200 Uwe Kleine-K__nig…

Hello,

Quoted 10 lines · Gregory Bean

Make gpio_unexport generate success instead of an -EINVAL if asked to unexport a line which is not exported, because the only result of that condition is a pr_debug which complains of what is really a harmless no-op:
when an unexported gpio is unexported again, nothing happens. That's not a failure, just a trivial border case. Since gpio_free calls gpio_unexport unconditionally and exported gpio lines are uncommon, most calls to gpio_free with debug flags enabled generate -EINVAL warnings in the log, causing unnecessary stress.

Quoted 8 lines
Quoted 6 lines

I noticed that a few days ago, too. Just didn't come around to fix it myself.

Quoted 1 line
Signed-off-by Gregory Bean <[email protected]>
Acked-by Uwe Kleine-K__nig <[email protected]>

Jon got there first ;)

OK, then he can get my ack, too.

Thanks
Uwe

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |