On Wed, 19 Sep 2018 15:03:11 -0700 David Frey <dpfrey@xxxxxxxxx> 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