On Sun, May 22, 2022 at 11:36:54AM +0100, Jonathan Cameron wrote: > > Syscall delete_module() tries to stop module first and after calls > > driver exit() function (which executes devm_* handlers inside, including IIO > > trigger unregister). It means we have the chicken or the egg dilemma here. > > Module can't be unloaded until module refcnt is not zero and we can't > > execute IIO trigger unregister (decrease module refcnt) only when module > > refcnt is zero. > > I suppose the possible solution to such a problem is a different semantic > > for internal triggers (inside driver itself) and external drivers (like > > hwtimer trigger). What do you think? > > Potentially though it's going to be tricky as a driver doesn't generally > have any way to know they are internal and we need to be careful not to > underflow the reference counts. We could hid a flag somewhere and > add an iio_trigger_get_same_owner() or something that sets that flag allowing > us to decide not to drop the reference count it if is automatically unassociated. > In the path where you get: > 1) iio_trigger_get_same_owner() on probe > 2) sysfs write changes to another trigger. > 3) sysfs write back to original trigger > it is reasonable to assume the need to clear the trigger > before driver removal is possible, whereas clearing the trigger association > if only step 1 happened is no intuitive. I will try to prepare the rfc patch if you don't mind. I propose to continue further discussion there. > > > > > The second one issue is located in the different IIO drivers. Some modules > > call iio_trigger_get() before iio_trigger_register(), trig->owner is not > > initialized to the right value (THIS_MODULE) and we don't acquire refcnt > > for proper driver object. > > Ah. Good point. I guess we missed that when we were moving over to > automated setting of the module. > Already submitted v2 patchset here: https://lore.kernel.org/linux-iio/20220524181150.9240-1-ddrokosov@xxxxxxxxxxxxxx/ -- Thank you, Dmitry
