From: Francesco Lavra <flavra@baylibre.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Lorenzo Bianconi" <lorenzo@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] iio: imu: st_lsm6dsx: set buffer sampling frequency for accelerometer only
Date: Mon, 12 Jan 2026 18:10:32 +0100 [thread overview]
Message-ID: <2ba028f8a6239c821da80ff487b9df5536e58169.camel@baylibre.com> (raw)
In-Reply-To: <20260111161857.4f8b4c35@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]
On Sun, 2026-01-11 at 16:18 +0000, Jonathan Cameron wrote:
> On Fri, 9 Jan 2026 19:15:26 +0100
> Francesco Lavra <flavra@baylibre.com> wrote:
>
> > The st_lsm6dsx_hwfifo_odr_store() function, which is called when
> > userspace
> > writes the buffer sampling frequency sysfs attribute, calls
> > st_lsm6dsx_check_odr(), which accesses the odr_table array at index
> > `sensor->id`; since this array is only 2 entries long, an access for
> > any
> > sensor type other than accelerometer or gyroscope is an out-of-bounds
> > access.
> >
> > To prevent userspace from triggering an out-of-bounds array access, and
> > to
> > support the only use case for which FIFO sampling frequency values
> > different from the sensor sampling frequency may be needed (which is
> > for
> > keeping FIFO data rate low while sampling acceleration data at high
> > rates
> > for accurate event detection), do not create the buffer sampling
> > frequency
> > attribute for sensor types other than the accelerometer.
>
> I'm not following why we need to drop this attribute for the gyroscope.
> Perhaps lay out what the combinations of controls are and the attributes
> we end up with.
It's not like we need to drop this attribute, it's just that I don't see a
need for it. The only reason I added this attribute was to be able to
control (e.g. lower) the rate of data coming from the sensor while
maintaining a high accuracy for event detection; and accurate event
detection requires a high sampling rate for the accelerometer. So the
gyroscope is not involved here, and the attribute is only needed for the
accelerometer.
Before this change, we have:
- accel IIO device with separate samp_freq and buffer/samp_freq
- gyro IIO device with separate samp_freq and buffer/samp_freq
- (optionally) external sensor IIO devices with separate samp_freq and
buffer/samp_freq (and trying to set buffer/samp_freq for these triggers an
out-of-bounds array access)
After this change, we have the accel IIO device with separate samp_freq and
buffer/samp_freq, while the other IIO devices have only a single samp_freq
attribute.
> As you note in the cover letter we can change this now with ABI issues as
> it is just in my tree, so I don't mind the change, just want to
> understand
> it a little better than I currently do!
It's not just in your tree, it has been pulled into Linus's tree for 6.19.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2026-01-12 17:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 18:15 [PATCH 0/3] imu: st_lsm6dsx: Add support for rotation sensor Francesco Lavra
2026-01-09 18:15 ` [PATCH 1/3] iio: imu: st_lsm6dsx: set buffer sampling frequency for accelerometer only Francesco Lavra
2026-01-11 16:18 ` Jonathan Cameron
2026-01-12 17:10 ` Francesco Lavra [this message]
2026-01-16 18:03 ` Jonathan Cameron
2026-01-16 19:06 ` Francesco Lavra
2026-01-16 20:35 ` Jonathan Cameron
2026-01-09 18:15 ` [PATCH 2/3] iio: imu: st_lsm6dsx: set FIFO ODR for accelerometer and magnetometer only Francesco Lavra
2026-01-09 19:09 ` Andy Shevchenko
2026-01-11 16:23 ` Jonathan Cameron
2026-01-11 16:26 ` Jonathan Cameron
2026-01-12 17:37 ` Francesco Lavra
2026-01-09 18:15 ` [PATCH 3/3] iio: imu: st_lsm6dsx: add support for rotation sensor Francesco Lavra
2026-01-09 19:22 ` Andy Shevchenko
2026-01-11 19:39 ` Jonathan Cameron
2026-01-11 16:46 ` Jonathan Cameron
2026-01-13 9:48 ` Francesco Lavra
2026-01-16 18:27 ` Jonathan Cameron
2026-01-16 19:26 ` 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=2ba028f8a6239c821da80ff487b9df5536e58169.camel@baylibre.com \
--to=flavra@baylibre.com \
--cc=andy@kernel.org \
--cc=dlechner@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®