On 06/09/2014 03:43 PM, David Laight wrote: > 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. The framework I have proposed is lock-less[1] and concurrent requests are serialized so both objections are invalid. [1]: in fact the framework uses spinlock, but only to protect internal list simple operations, and even this could be converted to fully lock-less implementation. Andrzej > > David > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |