For some reason gpiochip_export() would invalidate all the descriptors
of a chip if exporting it to sysfs failed. This does not appear as
necessary. Remove that part of the code.

While we are at it, add a note about the non-safety of temporarily
releasing a spinlock in the middle of the loop that protects its
iterator, and explain why this is done.

Signed-off-by: Alexandre Courbot <acour...@nvidia.com>
---
 drivers/gpio/gpiolib-sysfs.c | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
index 3516502059f2..f150aa288fa1 100644
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -760,18 +760,8 @@ int gpiochip_export(struct gpio_chip *chip)
        chip->exported = (status == 0);
        mutex_unlock(&sysfs_lock);
 
-       if (status) {
-               unsigned long   flags;
-               unsigned        gpio;
-
-               spin_lock_irqsave(&gpio_lock, flags);
-               gpio = 0;
-               while (gpio < chip->ngpio)
-                       chip->desc[gpio++].chip = NULL;
-               spin_unlock_irqrestore(&gpio_lock, flags);
-
+       if (status)
                chip_dbg(chip, "%s: status %d\n", __func__, status);
-       }
 
        return status;
 }
@@ -817,6 +807,14 @@ static int __init gpiolib_sysfs_init(void)
                if (!chip || chip->exported)
                        continue;
 
+               /*
+                * TODO we yield gpio_lock here because gpiochip_export()
+                * acquires a mutex. This is unsafe and needs to be fixed.
+                *
+                * Also it would be nice to use gpiochip_find() here so we
+                * can keep gpio_chips local to gpiolib.c, but the yield of
+                * gpio_lock prevents us from doing this.
+                */
                spin_unlock_irqrestore(&gpio_lock, flags);
                status = gpiochip_export(chip);
                spin_lock_irqsave(&gpio_lock, flags);
-- 
2.0.1

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

Reply via email to