Dne 14.8.2018 v 15:03 Mauro Carvalho Chehab napsal(a):
> Em Tue, 14 Aug 2018 11:35:01 +0300
> Sakari Ailus <sakari.ai...@linux.intel.com> escreveu:
>
>> Hi Pert,
>>
>> On Mon, Aug 13, 2018 at 06:33:12PM +0200, petrcve...@gmail.com wrote:
>>> From: Petr Cvek <petrcve...@gmail.com>
>>>
>>> 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
