Module get needed for iio_channel_get and friends

Jonathan, Lars:

I've noticed that iio_channel_{get, get_all} don't call try_module_get on the module associated to the indio_dev.

This means that an IIO driver can be removed while having a consumer for any of its channels.

If each channel can have a completely different indio_dev, this means we need to increase the refcount of the module on each indio_dev, right?

Quoted 5 lines · Ezequiel Garcia

Jonathan, Lars:

I've noticed that iio_channel_{get, get_all} don't call try_module_get on the module associated to the indio_dev.

Quoted 2 lines

This means that an IIO driver can be removed while having a consumer for any of its channels.

The device can still be unbound from the driver, even if you pin the module. E.g. device hot-unplug.

Quoted 4 lines

If each channel can have a completely different indio_dev, this means we need to increase the refcount of the module on each indio_dev, right?

I think we already handle this correctly. The device ref-count is incremented when a channel is requested. This means even when the device is unbound from the driver it will stay around until the channel is freed and the final reference is dropped. At the same time we set the info field of the IIO device to NULL when the driver is unbound from the driver and in iio_write_channel_raw() return -ENODEV when the info field is NULL.

Quoted 4 lines · Lars-Peter Clausen

Quoted 3 lines · Ezequiel Garcia

Jonathan, Lars:

I've noticed that iio_channel_{get, get_all} don't call

try_module_get

Quoted 3 lines

Quoted 3 lines

on the module associated to the indio_dev.

This means that an IIO driver can be removed while having a consumer

for

Quoted 6 lines

Quoted 1 line

any of its channels.

The device can still be unbound from the driver, even if you pin the module. E.g. device hot-unplug.

Hmm.. right.

Quoted 2 lines

Quoted 2 lines

If each channel can have a completely different indio_dev, this

means we

Quoted 1 line

Quoted 1 line

need to increase the refcount of the module on each indio_dev,

right?

Quoted 4 lines

Quoted 1 line

I think we already handle this correctly. The device ref-count is incremented when a channel is requested. This means even when the

device

Quoted 3 lines

is unbound from the driver it will stay around until the channel is freed and the final reference is dropped. At the same time we set the info field of the IIO device to NULL when the driver is unbound from

the

Quoted 1 line

driver and in iio_write_channel_raw() return -ENODEV when the info

field

Quoted 2 lines

is NULL.

Oh, I see.

So this means there's no way to prevent an IIO driver/device from being removed/unbinded if an IIO channel has been requested.

Somehow I thought the kernel was supposed to prevent such things, but guess I was wrong.

Thanks,