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

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

[Samuel Dionne-Riel]

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

I have done due diligence, and verified the assertion that the SMOCF05
is also the LSM6DS3TR-C. This was verified by looking closely at the
Windows driver, which also uses the LSM6DS3TR-C device identifier with
that ACPI hardware identifier.

From looking real close at the Windows driver, I am intuiting that this
different identifier is used to change how the driver behaves, but does
not materially change how the I2C device can work. Though I'm not 100%
sure of this assertion, I believe it does not matter at all for the
Linux driver.

This SMOCF05 configuration was tested on the Minisforum V3 SE.

For completion's sake, the device's DSDT data follows.

    Scope (_SB.I2CD)
    {
        Device (STS)
        {
            Name (_HID, EisaId ("SMOCF05"))  // _HID: Hardware ID
            Name (_CID, EisaId ("SMOCF05"))  // _CID: Compatible ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }
    
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x006A, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.I2CD",
                        0x00, ResourceConsumer, , Exclusive,
                        RawDataBuffer (0x04)  // Vendor Data
                        {
                            0x53, 0x4C, 0x41, 0x30
                        })
                    I2cSerialBusV2 (0x006A, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.I2CD",
                        0x00, ResourceConsumer, , Exclusive,
                        RawDataBuffer (0x04)  // Vendor Data
                        {
                            0x53, 0x4C, 0x47, 0x30
                        })
                    GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x0000,
                        "\\_SB.GPIO", 0x00, ResourceConsumer, ,
                        RawDataBuffer (0x04)  // Vendor Data
                        {
                            0x53, 0x4C, 0x41, 0x30
                        })
                        {   // Pin list
                            0x0009
                        }
                })
                Return (RBUF) /* \_SB_.I2CD.STS_._CRS.RBUF */
            }
    
            Method (SLA0, 0, NotSerialized)
            {
                Name (RBUF, Package (0x03)
                {
                    "-1 0 0",
                    "0 -1 0",
                    "0 0 -1"
                })
                Return (RBUF) /* \_SB_.I2CD.STS_.SLA0.RBUF */
            }
    
            Method (SLG0, 0, NotSerialized)
            {
                Name (RBUF, Package (0x03)
                {
                    "1 0 0",
                    "0 1 0",
                    "0 0 1"
                })
                Return (RBUF) /* \_SB_.I2CD.STS_.SLG0.RBUF */
            }
        }
    }

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 | 6 ++++++
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c  | 1 +
 2 files changed, 7 insertions(+)

-- 
2.51.0

[PATCH 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 | 1 +
 1 file changed, 1 insertion(+)

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

[PATCH 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.

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

diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
index 49ac17806e720..4bf1f7f7552d1 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
@@ -2707,6 +2707,12 @@ int st_lsm6dsx_probe(struct device *dev, int irq, int hw_id,
 			return err;
 	}
 
+	if (!iio_read_acpi_mount_matrix(hw->dev, &hw->orientation, "SLA0")) {
+		err = iio_read_mount_matrix(hw->dev, &hw->orientation);
+		if (err)
+			return err;
+	}
+
 	for (i = 0; i < ST_LSM6DSX_ID_MAX; i++) {
 		if (!hw->iio_devs[i])
 			continue;
-- 
2.51.0

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

[Jonathan Cameron]

On Mon, 22 Dec 2025 21:53:51 -0500
Samuel Dionne-Riel <samuel@dionne-riel.com> 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.
Hi Samuel

*sigh* More ACPI creativity.  Thanks for your detailed investigation.

I'm a bit curious why they didn't use the ones Microsoft defined
for windows but otherwise fine to support this.  A comment on the
approach below.

> 
> Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
> ---
>  drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> index 49ac17806e720..4bf1f7f7552d1 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> @@ -2707,6 +2707,12 @@ int st_lsm6dsx_probe(struct device *dev, int irq, int hw_id,
>  			return err;
>  	}
>  
> +	if (!iio_read_acpi_mount_matrix(hw->dev, &hw->orientation, "SLA0")) {
> +		err = iio_read_mount_matrix(hw->dev, &hw->orientation);
Whilst this 'works' this internal call is pointless as we already did this
if there was not match on ROTM just off the context visible here.

I think the way to do this cleanly is probably to have an st_read_acpi_mount_matrix()
helper that tries ROTM and SLA0 in turn.  Then have something like;

	if(!st_read_acpi_mount_matrix(hw->dev, &hw->orientation)) {
		err = iio_read_mount_matrix(hw->dev, &hw->orientation);
		if (err)
			return err;


	}
> +		if (err)
> +			return err;
> +	}
> +
>  	for (i = 0; i < ST_LSM6DSX_ID_MAX; i++) {
>  		if (!hw->iio_devs[i])
>  			continue;

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

[Jonathan Cameron]

On Mon, 22 Dec 2025 21:53:49 -0500
Samuel Dionne-Riel <samuel@dionne-riel.com> wrote:

> This patch set adds the alternative identifiers for the LSM6DS3TR-C,
> just like the windows driver allows.
> 
> I have done due diligence, and verified the assertion that the SMOCF05
> is also the LSM6DS3TR-C. This was verified by looking closely at the
> Windows driver, which also uses the LSM6DS3TR-C device identifier with
> that ACPI hardware identifier.
> 
> From looking real close at the Windows driver, I am intuiting that this
> different identifier is used to change how the driver behaves, but does
> not materially change how the I2C device can work. Though I'm not 100%
> sure of this assertion, I believe it does not matter at all for the
> Linux driver.
> 
> This SMOCF05 configuration was tested on the Minisforum V3 SE.

One passing comment inline.

> 
> For completion's sake, the device's DSDT data follows.
> 
>     Scope (_SB.I2CD)
>     {
>         Device (STS)
>         {
>             Name (_HID, EisaId ("SMOCF05"))  // _HID: Hardware ID
>             Name (_CID, EisaId ("SMOCF05"))  // _CID: Compatible ID
>             Name (_UID, Zero)  // _UID: Unique ID
>             Method (_STA, 0, NotSerialized)  // _STA: Status
>             {
>                 Return (0x0F)
>             }
>     
>             Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
>             {
>                 Name (RBUF, ResourceTemplate ()
>                 {
>                     I2cSerialBusV2 (0x006A, ControllerInitiated, 0x00061A80,
>                         AddressingMode7Bit, "\\_SB.I2CD",
>                         0x00, ResourceConsumer, , Exclusive,
>                         RawDataBuffer (0x04)  // Vendor Data
>                         {
>                             0x53, 0x4C, 0x41, 0x30
>                         })
>                     I2cSerialBusV2 (0x006A, ControllerInitiated, 0x00061A80,
>                         AddressingMode7Bit, "\\_SB.I2CD",
>                         0x00, ResourceConsumer, , Exclusive,
>                         RawDataBuffer (0x04)  // Vendor Data
>                         {
>                             0x53, 0x4C, 0x47, 0x30
>                         })
>                     GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x0000,
>                         "\\_SB.GPIO", 0x00, ResourceConsumer, ,
>                         RawDataBuffer (0x04)  // Vendor Data
>                         {
>                             0x53, 0x4C, 0x41, 0x30
>                         })
>                         {   // Pin list
>                             0x0009
>                         }
>                 })
>                 Return (RBUF) /* \_SB_.I2CD.STS_._CRS.RBUF */
>             }
>     
>             Method (SLA0, 0, NotSerialized)
>             {
>                 Name (RBUF, Package (0x03)
>                 {
>                     "-1 0 0",
>                     "0 -1 0",
>                     "0 0 -1"

That's not a rotation matrix... It's a rotoinversion which is
curious. That suggests one of these two sensor elements uses
right handed axis and the other left handed.

We just pass this stuff on to userspace though and don't enforce
that they are actually rotation matrices except by documentation.

>                 })
>                 Return (RBUF) /* \_SB_.I2CD.STS_.SLA0.RBUF */
>             }
>     
>             Method (SLG0, 0, NotSerialized)
>             {
>                 Name (RBUF, Package (0x03)
>                 {
>                     "1 0 0",
>                     "0 1 0",
>                     "0 0 1"
>                 })
>                 Return (RBUF) /* \_SB_.I2CD.STS_.SLG0.RBUF */
>             }
>         }
>     }
> 
> 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 | 6 ++++++
>  drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c  | 1 +
>  2 files changed, 7 insertions(+)
> 

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

[Andy Shevchenko]

On Mon, Dec 22, 2025 at 09:53:50PM -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.

...

>  static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>  	{ "SMO8B30", ST_LSM6DS3TRC_ID, },
> +	{ "SMOCF05", ST_LSM6DS3TRC_ID, },

The trailing inner comma is redundant. Perhaps it would be nice to have
a cleanup patch to remove existing one.

>  	{ }
>  };

-- 
With Best Regards,
Andy Shevchenko

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

[Andy Shevchenko]

On Mon, Dec 22, 2025 at 09:53:51PM -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.

...

> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> @@ -2707,6 +2707,12 @@ int st_lsm6dsx_probe(struct device *dev, int irq, int hw_id,
>  			return err;
>  	}
>  
> +	if (!iio_read_acpi_mount_matrix(hw->dev, &hw->orientation, "SLA0")) {
> +		err = iio_read_mount_matrix(hw->dev, &hw->orientation);
> +		if (err)
> +			return err;
> +	}

Seems that Accelerometer and Gyroscope have different methods, also the I²C
addresses and interrupt(s) are referring to the respective names in Vendor
Data fields. Perhaps that makes sense to also implement.

I,o,w, I don't think this patch is correct (place to put things in).

-- 
With Best Regards,
Andy Shevchenko