question about iio_dev.active_scan_mask

question about iio_dev.active_scan_mask

[David Frey]

Hi,

I am looking at struct iio_dev in include/linux/iio/iio.h and the
active_scan_mask member is documented as:

@active_scan_mask:   [INTERN] union of all scan masks requested by buffers

I believe that this is a bitmap where if bit X is set, that means the
channel with scan_index == X is enabled for buffering.

I believe that "[INTERN]" means that this member should not be accessed
by a device driver, but I see many device drivers iterating over the
bits of this field.  Is my understanding incorrect?  Perhaps "[INTERN]"
means that the field can be read from the driver, but should not be written.

Please help me clear up my understanding.

Thanks,
David

Re: question about iio_dev.active_scan_mask

[Jonathan Cameron]

On Wed, 19 Sep 2018 15:03:11 -0700
David Frey <dpfrey@gmail.com> wrote:

> Hi,
Hi David,

> 
> I am looking at struct iio_dev in include/linux/iio/iio.h and the
> active_scan_mask member is documented as:
> 
> @active_scan_mask:   [INTERN] union of all scan masks requested by buffers
> 
> I believe that this is a bitmap where if bit X is set, that means the
> channel with scan_index == X is enabled for buffering.

Correct. It represents the channels the device should be sampling,
which are not always the same as the ones that the driver's userspace interface
has configured as the channel demux may well be in use.

> 
> I believe that "[INTERN]" means that this member should not be accessed
> by a device driver, but I see many device drivers iterating over the
> bits of this field.  Is my understanding incorrect?  Perhaps "[INTERN]"
> means that the field can be read from the driver, but should not be written.

Yeah, this was a bit of historical mess we have slowly been cleaning out.
(or at least intending to clear out - as you've noted we haven't gotten
very far with it)

The upshot is they shouldn't access it directly, but only via the value
passed to the update_scan_mode callback. Now arguably we should reconsider
this given there are drivers in which the only thing that callback would
do is to take a copy of this field.  One that needs some more thought and
analysis of whether this is because there is actually a common case where
there are no optimizations that can be 'pre baked' in this callback, or
because they simply haven't been done yet for many of these parts.

This is one of those ugly corners I'd completely forgotten we still had
so glad you reminded us!

Jonathan

> 
> Please help me clear up my understanding.
> 
> Thanks,
> David