Dne 14.8.2018 v 10:35 Sakari Ailus napsal(a): > Hi Pert, > Hello, thanks for answering > 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. > Yeah it is a hack, but it allows me to rmmod the sensor driver. Otherwise it has a refcount "deadlock" as it holds the refcount on itself. The _only_ way to unload the driver is to reboot. ad clocks: Well the sensor driver and the controller are using v4l2_clk_* so I was poking around that. Anyway the independent clock object would be a problem, the clock control is inside the capture driver register set (divider, enable) (I think) and it gets gated out completely when the capture driver is unloaded. And when the clock is stopped the sensor isn't responding to i2c commands. The clock control is really dependent on the driver unless there is some callback to the sensor which interrupts it from non-responding i2c transfers. >> >> 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. > The ported sensor driver doesn't contain any media entity code. best regards, Petr
