On 30.11.2016 09:16, Laurent Pinchart wrote: > Hi Andrzej, > > On Wednesday 30 Nov 2016 09:11:56 Andrzej Hajda wrote: >> On 29.11.2016 22:12, Jyri Sarha wrote: >>> Store the module that provides the bridge and adjust its refcount >>> accordingly. The bridge module unload should not be allowed while the >>> bridge is attached. >> Module refcounting as a way of preventing driver from unbinding >> is quite popular, but as other developers said already is incorrect >> solution - it does not really prevent from unbinding and is a hack. > Absolutely, module refcounting must not be used as a way to prevent unbinding, > but it's still necessary to prevent functions from disappearing. The unbinding > race has to be fixed through reference counting to prevent objects from being > freed, but if an object contains function pointers that refer to code part of > a module, object refcounting won't prevent the code from being removed. Only > module refcounting helps there. The two techniques are thus complementary. It is not true. There at least two existing and proper solutions, which do not use refcounting: 1. components - if you put the bridge into component framework, it will bring down drm device before detaching the bridge. 2. proper callbacks from the provider (bridge in this case) to the consumer (encoder or drm device). Such callbacks exists for example in case of MIPI-DSI panels attached to encoders. On removal panel calls mipi_dsi_detach, which calls .detach ops in associated encoder, encoder safely disables the video pipeline and the panel continue its removal. Of course both solutions have some pitfalls, the first one removes whole drmdev instead of disabling one pipeline, the second one is specific for DSI bus, but they clearly shows refcounting is not the only option. Regards Andrzej _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
