This patch set adds the alternative identifier for the LSM6DS3TR-C,
just like the windows driver allows.

(For brevity, the methodology and DSDT fragment are not repeated from
the first version's cover letter of these changes.)

I have not made any change related to Andy Shevchenko's comments, other
than the cleanup, as I am lacking the context to understand what would
need to be done.

I am still sending this v2, not ignoring the request, but to at least
progress getting the device in a working state.

Changes since v1:
 - Reworked getting the matrix as st_read_acpi_mount_matrix().
 - Cleaned-up internal trailing comma in st_lsm6dsx_i2c_acpi_match.

v1: https://lore.kernel.org/linux-iio/20251223025351.3099978-2-samuel@dionne-riel.com/

Samuel Dionne-Riel (2):
  iio: imu: lsm6dsx: Support SMOCF05 ACPI ID for LSM6DS3TR-C
  iio: imu: lsm6dsx: Add alternative ACPI mount matrix retrieval

 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 9 ++++++++-
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c  | 3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)


base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
-- 
2.51.0

On Sun, Feb 01, 2026 at 05:54:48PM -0500, Samuel Dionne-Riel wrote:
> This patch set adds the alternative identifier for the LSM6DS3TR-C,
> just like the windows driver allows.

> (For brevity, the methodology and DSDT fragment are not repeated from
> the first version's cover letter of these changes.)

...which is needed for further discussions and in the formal commit message of
the respective patch (in some short form).

> I have not made any change related to Andy Shevchenko's comments, other
> than the cleanup, as I am lacking the context to understand what would
> need to be done.

The worry is about having SLA0 and SLG0 methods for mounting. Even if it's
the same device (like here) it might be better still to map the proper method
to the respective device. Id est if device is Gyroscope, use SLG0, if an
Accelerometer, use SLA0. Or did I misread the DSDT and this can't be achieved?

> I am still sending this v2, not ignoring the request, but to at least
> progress getting the device in a working state.

-- 
With Best Regards,
Andy Shevchenko

On Tue, Feb 03, 2026 at 01:39:15PM +0200, Andy Shevchenko wrote:
> On Sun, Feb 01, 2026 at 05:54:48PM -0500, Samuel Dionne-Riel wrote:
> > This patch set adds the alternative identifier for the LSM6DS3TR-C,
> > just like the windows driver allows.
> 
> > (For brevity, the methodology and DSDT fragment are not repeated from
> > the first version's cover letter of these changes.)
> 
> ...which is needed for further discussions and in the formal commit message of
> the respective patch (in some short form).
> 
> > I have not made any change related to Andy Shevchenko's comments, other
> > than the cleanup, as I am lacking the context to understand what would
> > need to be done.
> 
> The worry is about having SLA0 and SLG0 methods for mounting. Even if it's
> the same device (like here) it might be better still to map the proper method
> to the respective device. Id est if device is Gyroscope, use SLG0, if an
> Accelerometer, use SLA0. Or did I misread the DSDT and this can't be achieved?

And they also have vendor data to match the I2C resource and interrupt with
the actual user (and hence the method used). The Q was if we can use that
information to properly parse the _CRS and mount matrix methods.

> > I am still sending this v2, not ignoring the request, but to at least
> > progress getting the device in a working state.

-- 
With Best Regards,
Andy Shevchenko