linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: David Frey <dpfrey@gmail.com>
Cc: linux-iio <linux-iio@vger.kernel.org>
Subject: Re: question about iio_dev.active_scan_mask
Date: Thu, 20 Sep 2018 09:33:11 +0100	[thread overview]
Message-ID: <20180920093311.00004ec4@huawei.com> (raw)
In-Reply-To: <320ab010-4200-20cf-f71d-2fb77a2d1a67@gmail.com>

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

      reply	other threads:[~2018-09-20 14:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19 22:03 question about iio_dev.active_scan_mask David Frey
2018-09-20  8:33 ` Jonathan Cameron [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180920093311.00004ec4@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=dpfrey@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).