Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Nuno Sá" <noname.nuno@gmail.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/3] iio: cleanup masklength usage
Date: Sun, 28 Apr 2024 14:23:43 +0100	[thread overview]
Message-ID: <20240428142343.5067c898@jic23-huawei> (raw)
In-Reply-To: <CAMknhBGQB4MC8ejEs_uLgb=iKehXkoetgHjZnCvCKQbuua5kfA@mail.gmail.com>

On Fri, 26 Apr 2024 10:26:31 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On Fri, Apr 26, 2024 at 2:13 AM Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > On Thu, 2024-04-25 at 10:03 -0500, David Lechner wrote:  
> > > While working on other patches I noticed that a few drivers are setting
> > > the masklength field of struct iio_dev even though it is marked as
> > > [INTERN]. It looks like maybe this was not always the case, but we can
> > > safely clean it up now without breaking anything.
> > >
> > > ---
> > > David Lechner (3):
> > >       iio: adc: ad7266: don't set masklength
> > >       iio: adc: mxs-lradc-adc: don't set masklength
> > >       iio: buffer: initialize masklength accumulator to 0
> > >
> > >  drivers/iio/adc/ad7266.c          | 1 -
> > >  drivers/iio/adc/mxs-lradc-adc.c   | 1 -
> > >  drivers/iio/industrialio-buffer.c | 2 +-
> > >  3 files changed, 1 insertion(+), 3 deletions(-)
> > > ---
> > > base-commit: b80ad8e3cd2712b78b98804d1f59199680d8ed91
> > > change-id: 20240425-b4-iio-masklength-cleanup-86b632b19901
> > >  
> >
> > Hi David,
> >
> > Nice cleanup. The patches look good to me but there's one thing missing :). As you
> > correctly noted, the field should be internal to the IIO core and drivers should not
> > touch it. Hence, you need to make sure not driver is using it so we can move it into
> > struct iio_dev_opaque [1]. That's the place all the intern fields should, eventually,
> > end up.
> >
> > Now, quite some drivers in the trigger handler will read the masklength for looping
> > with for_each_set_bit(). Hence, the straight thing would be an helper to get it.
> > Maybe there's a clever way...
> >
> > I know this is more work than what you had in mind but I think it should be fairly
> > simple (hopefully) and since you started it :), maybe we can get the whole thing done
> > and remove another [INTERN] member from the iio_dev struct.
> >
> > [1]: https://elixir.bootlin.com/linux/latest/source/include/linux/iio/iio-opaque.h#L42
> >
> > - Nuno Sá  
> 
> Sounds like fun. :-p
> 
> I will look into it.

I think this one might be miss marked as [INTERN]. It should be constant from the driver
point of view, but given active_scan_masks is meant to be visible to the driver,
it's length should probably be as well.

Sure every driver should be able to trivially work this out for themselves, but
do we care about stopping them using this?

It might be worth some nice iterator wrappers with names like
iio_for_each_active_channel() though I'd expect those to still be accessing these
fields directly as this is a high performance path so we don't want to to bounce
though a core function to get them.

Jonathan

  reply	other threads:[~2024-04-28 13:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-25 15:03 [PATCH 0/3] iio: cleanup masklength usage David Lechner
2024-04-25 15:03 ` [PATCH 1/3] iio: adc: ad7266: don't set masklength David Lechner
2024-04-25 15:03 ` [PATCH 2/3] iio: adc: mxs-lradc-adc: " David Lechner
2024-04-25 15:03 ` [PATCH 3/3] iio: buffer: initialize masklength accumulator to 0 David Lechner
2024-04-26  7:13 ` [PATCH 0/3] iio: cleanup masklength usage Nuno Sá
2024-04-26 15:26   ` David Lechner
2024-04-28 13:23     ` Jonathan Cameron [this message]
2024-04-29  7:17       ` Nuno Sá
2024-04-28 13:27 ` Jonathan Cameron

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=20240428142343.5067c898@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=dlechner@baylibre.com \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noname.nuno@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@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