lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ