Hi Jean,
> On Jan 14, 2015, at 19:14 , Jean Delvare <jdelvare@xxxxxxx> wrote:
>
> Hi Guenter,
>
> On Wed, 14 Jan 2015 08:24:43 -0800, Guenter Roeck wrote:
>> On Wed, Jan 14, 2015 at 04:15:25PM +0100, Jean Delvare wrote:
>>> I did that. On my system the i2c-i801 driver instantiates an
>>> i2c-mux-gpio device. Unloading the i2c-i801 driver removes that device
>>> and it works fine. Note however that I am not able to unload module
>>> i2c-i801 immediately, I have to unload module i2c-mux-gpio first, as
>>> the latter holds a reference to the former. This is because
>>> i2c-mux-gpio calls i2c_get_adapter() on the parent I2C bus segment at
>>> probing time.
>>>
>>> I see that i2c-mux-pinctrl does the same, but i2c-mux-pca954x and
>>> i2c-mux-pca9541 do not. This might be an issue. I doubt this is related
>>> to your problem though, as these are module references and not device
>>> references.
>>
>> Should we add get/put functions to those drivers ?
>
> I'm not sure. If you unload a driver which instantiated a pca9540-like
> device, without unloading i2c-mux-pca954x first, does something bad
> happen?
>
I’m not sure this got anything to do with module reference. The problem
lies at the device model’s reference counts.
I’ll try to dig around tomorrow and see what the real device reference counts
are, but my hunch goes like this:
MUX
+—- ADAPTER
+— DEV.
Mux remove method is called, i2c_del_mux_adapter is called on all the channels
of the mux, calling in turn i2c_del_adapter which hangs on completion of the
dev_released.
The call to device_unregister never calls the device_type callback (i2c_adapter_dev_release)
because the reference count is not 1 at that point, someone else is having another
reference.
I guess we could use Greg’s ideas on the matter.
> --
> Jean Delvare
> SUSE L3 Support
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
