From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Herman van Hazendonk" <github.com@herrie.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
"Denis Ciocca" <denis.ciocca@gmail.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Denis Ciocca" <denis.ciocca@st.com>,
"Linus Walleij" <linusw@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, devicetree@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] iio: common: st_sensors: honour channel endianness in read_axis_data
Date: Tue, 23 Jun 2026 20:23:34 +0100 [thread overview]
Message-ID: <20260623202334.2217b1d4@jic23-huawei> (raw)
In-Reply-To: <ajJwzsIMxX3Ew1x_@ashevche-desk.local>
On Wed, 17 Jun 2026 13:02:54 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Jun 16, 2026 at 03:02:04PM +0200, Herman van Hazendonk wrote:
> > st_sensors_read_axis_data() unconditionally decoded multi-byte
> > results with get_unaligned_le16() / get_unaligned_le24() regardless
> > of the channel's declared scan_type.endianness.
> >
> > For every ST sensor that has used this helper since it was introduced
> > this happened to be fine because the ST IMU/accel/gyro/pressure
> > families publish their data registers as little-endian and the
> > channel specs in those drivers declare IIO_LE accordingly.
> >
> > The LSM303DLH magnetometer however publishes its X/Y/Z output as a
> > pair of big-endian bytes (the H register sits at the lower address,
> > 0x03/0x05/0x07, and the L register immediately after), and its
> > channel specs in st_magn_core.c correctly declare IIO_BE -- but
> > read_axis_data() ignored that and decoded as little-endian, swapping
> > the high and low bytes of every magnetometer sample. The LSM303DLHC
> > and LSM303DLM share the same st_magn_16bit_channels (IIO_BE) and
> > were therefore byte-swapped by the same bug; users of those parts
> > will see different in_magn_*_raw values after this fix lands.
> >
> > The bug is most visible on a stationary chip: in earth's field the
> > true X reading is small and the high byte sits at 0x00, so swapping
> > the bytes pins sysfs X at exactly the low byte's pattern (e.g. 0x00F0
> > = 240). Y and Z still appear "to vary" because their magnitudes are
> > larger and the noise in the low byte produces big swings in the
> > swapped high byte:
> >
> > before (LSM303DLH flat, sysfs in_magn_*_raw):
> > X=240 (stuck), Y= 12032..23296, Z=-16128..-9728
> >
> > after (direct i2c-dev big-endian decode, same chip same orientation):
> > X≈-4096, Y≈210, Z≈80 (sensible values reflecting earth's
> > ambient field at low gauss range)
> >
> > Fix read_axis_data() to dispatch on ch->scan_type.endianness and
> > call get_unaligned_be16() / get_unaligned_be24() when the channel
> > declares IIO_BE. Existing IIO_LE consumers (st_accel, st_gyro,
> > st_pressure, st_lsm6dsx and others) are unaffected because their
> > channel specs already declare IIO_LE and the LE path is unchanged.
> >
> > While restructuring the branches, replace the previously implicit
> > silent-success-with-uninitialised-*data fall-through for
> > byte_for_channel outside 1..3 with an explicit return -EINVAL. No
> > in-tree ST sensor publishes such a channel, but the new behaviour
> > is strictly safer than handing userspace garbage.
>
> Sounds like inevitable change in ABI, but worth doing it.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Applied to the fixes-togreg branch of iio.git. I'll wait until after
rc1 to send a pull request though (and rebase on rc1 in the meantime).
The other patches may have to wait, I haven't checked yet!
Jonathan
>
next prev parent reply other threads:[~2026-06-23 19:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 13:02 [PATCH v2 0/3] iio: lsm303dlh-magn: endianness + boot-time fullscale selection Herman van Hazendonk
2026-06-16 13:02 ` [PATCH v2 1/3] iio: common: st_sensors: honour channel endianness in read_axis_data Herman van Hazendonk
2026-06-17 10:02 ` Andy Shevchenko
2026-06-23 19:23 ` Jonathan Cameron [this message]
2026-06-16 13:02 ` [PATCH v2 2/3] dt-bindings: iio: st,st-sensors: add st,fullscale-milligauss Herman van Hazendonk
2026-06-16 15:41 ` Conor Dooley
2026-06-23 19:26 ` Jonathan Cameron
2026-06-16 13:02 ` [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property Herman van Hazendonk
2026-06-17 10:05 ` Andy Shevchenko
2026-06-23 19:29 ` Jonathan Cameron
2026-06-23 19:49 ` Andy Shevchenko
2026-06-24 4:18 ` me
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=20260623202334.2217b1d4@jic23-huawei \
--to=jic23@kernel.org \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=denis.ciocca@gmail.com \
--cc=denis.ciocca@st.com \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=github.com@herrie.org \
--cc=justinstitt@google.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linusw@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=stable@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