[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251227180446.45836e37@jic23-huawei>
Date: Sat, 27 Dec 2025 18:04:46 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Samuel Dionne-Riel <samuel@...nne-riel.com>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>, David Lechner
<dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy
Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID
On Mon, 22 Dec 2025 21:53:49 -0500
Samuel Dionne-Riel <samuel@...nne-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(+)
>
Powered by blists - more mailing lists