From: Of Andrzej Hajda ... > > You can't error out on module unload, although that's not really relevant > > here. gpiochip_remove() is typically called when the device that registered > > the GPIO chip is unbound. And despite some remove() callbacks having a > > return type of int you can not abort the removal of a device. > > It is a design flaw in many subsystems having providers and consumers, > not only GPIO. The same situation is with clock providers, regulators, > phys, drm_panels, ..., at least it was such last time I have tested it. > > The problem is that many frameworks assumes that lifetime of provider is > always bigger than lifetime of its consumers, and this is wrong > assumption - usually it is not possible to prevent unbinding driver from > device, so if the device is a provider there is no way to inform > consumers about his removal. > > Some solution for such problems is to use some kind of availability > callbacks for requesting resources (gpios, clocks, regulators,...) > instead of simple 'getters' (clk_get, gpiod_get). Callbacks should > guarantee that the resource is always valid between callback reporting > its availability and callback reporting its removal. Such approach seems > to be complicated at the first sight but it should allow to make the > code safe and as a bonus it will allow to avoid deferred probing. > Btw I have send already RFC for such framework [1]. Callbacks for delete are generally a locking nightmare. A two-way handshake is also usually needed to avoid problems with concurrent disconnect requests. David
