On Fri, Sep 05, 2014 at 06:17:59PM +0300, Octavian Purdila wrote:
> +static int dln2_do_remove(struct dln2_gpio *dln2)
> +{
> + /* When removing the DLN2 USB device, gpiochip_remove may fail
> + * due to i2c drivers holding a GPIO pin. However, the i2c bus
> + * will eventually be removed triggering an i2c driver remove
> + * which will release the GPIO pin. So retrying the operation
> + * later should succeed. */
> + int ret = gpiochip_remove(&dln2->gpio);
> + struct device *dev = dln2->gpio.dev;
> +
> + if (ret < 0) {
> + if (ret == -EBUSY)
> + schedule_delayed_work(&dln2->remove_work.work, HZ/10);
> + else
> + dev_warn(dev, "error removing gpio chip: %d\n", ret);
> + } else {
> + kfree(dln2);
> + }
> +
> + return ret;
> +}
Apparently, the return value from gpiochip_remove is going away:
"Start to kill off the return value from gpiochip_remove() by
removing the __must_check attribute and removing all checks
inside the drivers/gpio directory. The rationale is: well what
were we supposed to do if there is an error code? Not much:
print an error message. And gpiolib already does that. So make
this function return void eventually."
https://www.mail-archive.com/linux-gpio@xxxxxxxxxxxxxxx/msg03468.html
Also, have you considered what happens if there are gpios exported
through sysfs? These may never be released.
In general, how well have these patches been tested with disconnect
events? At least gpiolib is known to blow up (sooner or later) when a
gpiochip is removed when having requested gpios.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
