From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Francesco Lavra <flavra@baylibre.com>
Cc: "Lorenzo Bianconi" <lorenzo@kernel.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 8/9] iio: imu: st_lsm6dsx: add event configurability on a per axis basis
Date: Thu, 20 Nov 2025 10:05:27 +0100 [thread overview]
Message-ID: <aR7Z19wgPksymwkw@black.igk.intel.com> (raw)
In-Reply-To: <82bf13fd5ada664d9e4fdbc3ee453204e55d318b.camel@baylibre.com>
On Tue, Nov 18, 2025 at 12:01:57PM +0100, Francesco Lavra wrote:
> On Tue, 2025-11-18 at 11:44 +0100, Andy Shevchenko wrote:
> > On Mon, Nov 17, 2025 at 08:23:35PM +0100, Francesco Lavra wrote:
> > > On Thu, 2025-10-30 at 15:56 +0200, Andy Shevchenko wrote:
> > > > On Thu, Oct 30, 2025 at 12:23:19PM +0100, Francesco Lavra wrote:
> > > > > On Thu, 2025-10-30 at 10:24 +0200, Andy Shevchenko wrote:
> > > > > > On Thu, Oct 30, 2025 at 08:27:51AM +0100, Francesco Lavra wrote:
...
> > > > > > > + old_enable = hw->enable_event[event];
> > > > > > > + new_enable = state ? (old_enable | BIT(axis)) :
> > > > > > > (old_enable
> > > > > > > &
> > > > > > > ~BIT(axis));
> > > > > > > + if (!!old_enable == !!new_enable)
> > > > > >
> > > > > > This is an interesting check. So, old_enable and new_enable are
> > > > > > _not_
> > > > > > booleans, right?
> > > > > > So, this means the check test if _any_ of the bit was set and
> > > > > > kept
> > > > > > set or
> > > > > > none were set
> > > > > > and non is going to be set. Correct? I think a short comment
> > > > > > would be
> > > > > > good to have.
> > > > >
> > > > > old_enable and new_enable are bit masks, but we are only interested
> > > > > in
> > > > > whether any bit is set, to catch the cases where the bit mask goes
> > > > > from
> > > > > zero to non-zero and vice versa. Will add a comment.
> > > >
> > > > If it's a true bitmask (assuming unsigned long type) then all this
> > > > can be
> > > > done
> > > > via bitmap API calls. Otherwise you can also compare a Hamming
> > > > weights of
> > > > them
> > > > (probably that gives even the same size of the object file, but !!
> > > > instructions
> > > > will be changed to hweight() calls (still a single assembly instr on
> > > > modern
> > > > architectures).
> > >
> > > These are u8 variables, so we can't use the bitmap API.
> >
> > OK. But hweight8() can still be used.
> >
> > > And I don't
> > > understand the reason for using hweight(), given that the !! operators
> > > would still be needed.
> >
> > No, you won't need !! with that.
>
> I still don't understand. Are you proposing to replace `if (!!old_enable ==
> !!new_enable)` with `if (hweight8(old_enable) == hweight8(new_enable))`?
> That won't work, because we only need to check whether the Hamming weight
> goes from zero to non-zero and vice versa.
old_enable = hw->enable_event[event];
new_enable = state ? (old_enable | BIT(axis)) :
(old_enable & ~BIT(axis));
if (!!old_enable == !!new_enable)
return 0;
If I am not mistaken this will do exactly the same in a simpler way.
old_enable = hw->enable_event[event];
if (state)
new_enable = old_enable | BIT(axis);
else
new_enable = old_enable & ~BIT(axis);
if ((new_enable ^ old_enable) != BIT(axis))
return 0;
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-11-20 9:05 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 7:27 [PATCH 0/9] st_lsm6dsx: add tap event detection Francesco Lavra
2025-10-30 7:27 ` [PATCH 1/9] iio: imu: st_lsm6dsx: dynamically initialize iio_chan_spec data Francesco Lavra
2025-10-30 7:57 ` Andy Shevchenko
2025-10-30 11:03 ` Francesco Lavra
2025-10-30 16:42 ` Lorenzo Bianconi
2025-10-31 8:04 ` Francesco Lavra
2025-10-31 8:09 ` Andy Shevchenko
2025-10-31 8:26 ` Francesco Lavra
2025-10-31 8:32 ` Andy Shevchenko
2025-10-31 11:43 ` Francesco Lavra
2025-11-02 11:16 ` Jonathan Cameron
2025-11-03 9:24 ` Francesco Lavra
2025-11-09 13:32 ` Jonathan Cameron
2025-10-30 7:27 ` [PATCH 2/9] iio: imu: st_lsm6dsx: make event_settings more generic Francesco Lavra
2025-10-30 16:44 ` Lorenzo Bianconi
2025-10-31 8:08 ` Francesco Lavra
2025-10-30 7:27 ` [PATCH 3/9] iio: imu: st_lsm6dsx: move wakeup event enable mask to event_src Francesco Lavra
2025-10-30 7:59 ` Andy Shevchenko
2025-10-30 7:27 ` [PATCH 4/9] iio: imu: st_lsm6dsx: dynamically allocate iio_event_spec structs Francesco Lavra
2025-11-02 11:22 ` Jonathan Cameron
2025-10-30 7:27 ` [PATCH 5/9] iio: imu: st_lsm6dsx: rework code to check for enabled events Francesco Lavra
2025-10-30 7:27 ` [PATCH 6/9] iio: imu: st_lsm6dsx: remove event_threshold field from hw struct Francesco Lavra
2025-10-30 8:01 ` Andy Shevchenko
2025-10-30 11:10 ` Francesco Lavra
2025-10-30 13:49 ` Andy Shevchenko
2025-11-02 11:29 ` Jonathan Cameron
2025-11-02 13:45 ` Andy Shevchenko
2025-11-03 9:34 ` Francesco Lavra
2025-11-03 9:40 ` Andy Shevchenko
2025-11-03 14:53 ` David Lechner
2025-11-09 13:31 ` Jonathan Cameron
2025-10-30 7:27 ` [PATCH 7/9] iio: imu: st_lsm6dsx: make event management functions generic Francesco Lavra
2025-10-30 8:15 ` Andy Shevchenko
2025-10-30 11:17 ` Francesco Lavra
2025-10-30 13:36 ` Andy Shevchenko
2025-11-02 11:33 ` Jonathan Cameron
2025-10-30 7:27 ` [PATCH 8/9] iio: imu: st_lsm6dsx: add event configurability on a per axis basis Francesco Lavra
2025-10-30 8:24 ` Andy Shevchenko
2025-10-30 11:23 ` Francesco Lavra
2025-10-30 13:56 ` Andy Shevchenko
2025-11-17 19:23 ` Francesco Lavra
2025-11-18 10:44 ` Andy Shevchenko
2025-11-18 11:01 ` Francesco Lavra
2025-11-20 9:05 ` Andy Shevchenko [this message]
2025-11-20 11:43 ` Francesco Lavra
2025-11-20 13:59 ` Andy Shevchenko
2025-11-20 18:31 ` Andy Shevchenko
2025-11-21 9:14 ` Francesco Lavra
2025-11-21 9:31 ` Andy Shevchenko
2025-11-21 14:57 ` Francesco Lavra
2025-12-07 15:11 ` Jonathan Cameron
2025-10-30 7:27 ` [PATCH 9/9] iio: imu: st_lsm6dsx: add tap event detection Francesco Lavra
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=aR7Z19wgPksymwkw@black.igk.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=dlechner@baylibre.com \
--cc=flavra@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=nuno.sa@analog.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.