[PATCH v2 0/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID

[PATCH v2 0/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID

[Samuel Dionne-Riel]

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

[PATCH v2 1/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID for LSM6DS3TR-C

[Samuel Dionne-Riel]

Same device (LSM6DS3TR-C), different integration with the firmware.

The integration differs in that the firmware provides the SLA0 and SLG0
mounting matrices. They are assumed to be Accelerometer and Gyroscope.

Observations were made against the Windows driver, version
`12/06/2023,1.0.4.3`. This driver supports both identifiers, but expose
the device in different ways.

Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
---
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
index 7c933218036b8..10002f05b45f5 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
@@ -143,7 +143,8 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
 MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
 
 static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
-	{ "SMO8B30", ST_LSM6DS3TRC_ID, },
+	{ "SMO8B30", ST_LSM6DS3TRC_ID },
+	{ "SMOCF05", ST_LSM6DS3TRC_ID },
 	{ }
 };
 MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
-- 
2.51.0

[PATCH v2 2/2] iio: imu: lsm6dsx: Add alternative ACPI mount matrix retrieval

[Samuel Dionne-Riel]

This uses the SLA0 matrix, which is how the SMOCF05 configuration
exposes the mounting information for the accelerometer.

On a limited sample size of one (1) unit, the SLG0 matrix is the
identity matrix. It is unknown how the SLG0 mounting matrix would
logically affect the data, if it differed from the identity matrix.
After all, the IMU is mounted as one single unit, its mounting can't
differ on the gyroscope compared to the accelerometer.

The new `st_lsm6dsx_read_acpi_mount_matrix` function currently only
implements the *known* ACPI methods found in the wild, but the windows
driver seems to indicate more integration-specific methods could exist.

Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
---
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
index dc78227952a7c..2278cbf2b711f 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
@@ -2635,6 +2635,13 @@ static int st_lsm6dsx_init_regulators(struct device *dev)
 	return 0;
 }
 
+static bool st_lsm6dsx_read_acpi_mount_matrix(struct device *dev,
+				      struct iio_mount_matrix *orientation)
+{
+	return iio_read_acpi_mount_matrix(dev, orientation, "ROTM") ||
+		iio_read_acpi_mount_matrix(dev, orientation, "SLA0");
+}
+
 int st_lsm6dsx_probe(struct device *dev, int irq, int hw_id,
 		     struct regmap *regmap)
 {
@@ -2708,7 +2715,7 @@ int st_lsm6dsx_probe(struct device *dev, int irq, int hw_id,
 			return err;
 	}
 
-	if (!iio_read_acpi_mount_matrix(hw->dev, &hw->orientation, "ROTM")) {
+	if (!st_lsm6dsx_read_acpi_mount_matrix(hw->dev, &hw->orientation)) {
 		err = iio_read_mount_matrix(hw->dev, &hw->orientation);
 		if (err)
 			return err;
-- 
2.51.0

Re: [PATCH v2 2/2] iio: imu: lsm6dsx: Add alternative ACPI mount matrix retrieval

[Andy Shevchenko]

On Sun, Feb 01, 2026 at 05:54:50PM -0500, Samuel Dionne-Riel wrote:
> This uses the SLA0 matrix, which is how the SMOCF05 configuration
> exposes the mounting information for the accelerometer.
> 
> On a limited sample size of one (1) unit, the SLG0 matrix is the
> identity matrix. It is unknown how the SLG0 mounting matrix would
> logically affect the data, if it differed from the identity matrix.
> After all, the IMU is mounted as one single unit, its mounting can't
> differ on the gyroscope compared to the accelerometer.
> 
> The new `st_lsm6dsx_read_acpi_mount_matrix` function currently only

st_lsm6dsx_read_acpi_mount_matrix()

> implements the *known* ACPI methods found in the wild, but the windows

Windows

> driver seems to indicate more integration-specific methods could exist.

...

> +static bool st_lsm6dsx_read_acpi_mount_matrix(struct device *dev,
> +				      struct iio_mount_matrix *orientation)
> +{
> +	return iio_read_acpi_mount_matrix(dev, orientation, "ROTM") ||
> +		iio_read_acpi_mount_matrix(dev, orientation, "SLA0");

Indentation is incorrect.

> +}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID for LSM6DS3TR-C

[Andy Shevchenko]

On Sun, Feb 01, 2026 at 05:54:49PM -0500, Samuel Dionne-Riel wrote:
> Same device (LSM6DS3TR-C), different integration with the firmware.
> 
> The integration differs in that the firmware provides the SLA0 and SLG0
> mounting matrices. They are assumed to be Accelerometer and Gyroscope.
> 
> Observations were made against the Windows driver, version
> `12/06/2023,1.0.4.3`. This driver supports both identifiers, but expose
> the device in different ways.

Does it imply mount matrix method? Then patches should be in reversed order to
avoid adding not properly working device.

...

Also this needs an ACPI excerpt from DSDT of the machine in a wild along with
its model. (The ACPI ID looks fine, IIRC SMO is registered PNP ID).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID

[Andy Shevchenko]

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

Re: [PATCH v2 0/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID

[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