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

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(+)
>