Dne 14.8.2018 v 15:03 Mauro Carvalho Chehab napsal(a): > Em Tue, 14 Aug 2018 11:35:01 +0300 > Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> escreveu: > >> Hi Pert, >> >> On Mon, Aug 13, 2018 at 06:33:12PM +0200, petrcvekcz@xxxxxxxxx wrote: >>> From: Petr Cvek <petrcvekcz@xxxxxxxxx> >>> >>> When transferring a media sensor driver from the soc_camera I've found >>> the controller module can get removed (which will cause a stack dump >>> because the sensor driver depends on resources from the controller driver). >> >> There may be a kernel oops if a resource used by another driver goes away. >> But the right fix isn't to prevent unloading that module. Instead, one way >> to address the problem would be to have persistent clock objects that would >> not be dependent on the driver that provides them. >> >>> >>> When I've tried to remove the driver module of the sensor it said the >>> resource was busy (without a reference name) though is should be >>> possible to remove the sensor driver because it is at the end of >>> the dependency list and not to remove the controller driver. >> >> That might be one day possible but it is not today. >> >> You'll still need to acquire the sensor module as well as it registers a >> media entity as well as a sub-device. > > Let put my 2 cents here. > > Usually, the same problem of removing modules happen if you just > ask the driver's core to unbind a module (with can be done via > sysfs). > > Removing/unbinding a driver that uses media controller should work, > if the unbinding code at the driver (e. g. i2c_driver::remove field) > would delete the media controller entities, and the caller driver > doesn't cache it. > Yeah I assume it would be same as removing my sensor module from v4l2_async and unregistering v4l2 clocks. Petr
