Re: [PATCH v3 2/2] iio: imu: st_lsm6dsx: Add ACPI ID SMOCF05 for LSM6DS3TR-C

[Jared Wuerzburger <jwuerz@gmail.com>]

On Mon, Sep 28, 2026 at 12:13:17PM +0300, Andy Shevchenko wrote:
> On Sun, Sep 27, 2026 at 05:05:59PM -0500, Jared Wuerzburger wrote:

...

> > Relevant part of the DSDT, identical on both models (full excerpt in
> > the cover letter):
>
> Don't refer to the cover letter in the commit message. Most will not understand
> this pointer.

Makes sense, I'll drop it.

> >   Scope (_SB.I2CD) { Device (STS) {

...

> Just ask maintainer to add a Link tag to the series instead.

Will do. In v4 the short excerpt stays in the commit message, without
the pointer, and I'll ask Jonathan below the --- line to add a Link:
to the series when applying, so the full excerpt in the cover letter
stays reachable from the commit.

> > Both I2C resources describe the same address, and the driver uses the
> > first one. The vendor-specific SLA0/SLG0 mount matrices are not parsed
> > here; the accelerometer orientation is handled in userspace through
> > the systemd hwdb, as for SMOCF00.
>
> Hmm... But is that wrong? I mean does ACPI provide the correct data in mount
> matrix?

Good question, and it made me check more carefully: X and Y are right,
Z isn't. SLA0 (-1 0 0; 0 -1 0; 0 0 -1) matches the Windows sensor
convention, which reports the gravity vector (Z = -1g with the screen
facing up). SLG0 being identity fits that: SLA0's negation is a sign
convention, not a mounting rotation. With it applied via hwdb,
auto-rotation on my V3 is correct (that only depends on the X and Y
signs), but iio-sensor-proxy reports the tilt inverted: "tilted-down"
with the screen leaning back. With -1 0 0; 0 -1 0; 0 0 1, a plain
180 degree rotation about Z, orientation and tilt are both right. That
means the systemd hwdb entry that went in today [1] has the wrong Z
sign; the fix is here [2].

So the firmware values can't be used as a mount matrix as they are;
reading SLA0 like ROTM, as v2 did, would have exported the same wrong
Z. That's one more reason I'd keep this series to the ID and leave the
orientation to hwdb, as was done for SMOCF00. If you'd still like the
firmware data used in the driver, I'm happy to look at it as a
follow-up, but it would need translating from the Windows convention
rather than using it as a mount matrix.

> > Link: https://github.com/mudkipme/awesome-minisforum-v3/issues/2
>
> Closes?

Yes, I'll switch it to Closes: in v4.

> > Assisted-by: Claude:claude-opus-5-5
>
> Assisted-by: LLM

Will fix, same as in 1/2.

[1] https://github.com/systemd/systemd/pull/43935
[2] https://github.com/systemd/systemd/pull/43941

Jared