On Wed, Sep 24, 2014 at 11:51 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Fri, Sep 5, 2014 at 5:22 PM, Octavian Purdila > <octavian.purdila@xxxxxxxxx> wrote: > >> The current implementation of gpiochip_remove() does not check to see >> if the GPIO pins are busy before removing the associated irqchip and >> this is causing the following warning: > (...) >> A retry operation is needed in the case of MFD devices that bundles a >> GPIO device and another device that is an indirect consumer of the >> GPIO device (typical an I2C bus). > > We have just finalized a set of patches making gpiochip_remove() > not return an error code, because it just must work. > > It seems like this patch want us to sort of reverse that whole train > of work and go back to the old style of having gpiochip_remove() > be able to fail :-/ > > I would suggest that if this usecase is to be supported for thing > like MFD devices, we need to introduce gpiochip_try_remove() > in parallel with the current implementation, so that those drivers > that actually want to retry the remove the chip can use that > interface explicitly. > > Can you look into this option? > > Please also look over gpiochip_remove() as it looks right now > in linux-next... > I was not aware of the changes to gpiochip_remove() when I sent this patch and I do agree that it is better to have gpiochip_remove() not be able to fail. The main issue is actually with USB devices not necessarily MFD. If the USB device is unplugged while IRQ GPIOs are requested then I see the issues mentioned in the patch. I will try to rework the patch to use the assumption that gpiochip_remove() must not fail. That will likely need adding some reference counting when calling gpiod_request() and gpiod_free(). -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html