From: Jonathan Cameron <jic23@kernel.org>
To: Samuel Dionne-Riel <samuel@dionne-riel.com>
Cc: "Lorenzo Bianconi" <lorenzo@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID
Date: Sat, 27 Dec 2025 18:04:46 +0000 [thread overview]
Message-ID: <20251227180446.45836e37@jic23-huawei> (raw)
In-Reply-To: <20251223025351.3099978-2-samuel@dionne-riel.com>
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(+)
>
prev parent reply other threads:[~2025-12-27 18:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-23 2:53 Samuel Dionne-Riel
2025-12-23 2:53 ` [PATCH 1/2] iio: imu: lsm6dsx: Support SMOCF05 ACPI ID for LSM6DS3TR-C Samuel Dionne-Riel
2025-12-28 17:18 ` Andy Shevchenko
2025-12-23 2:53 ` [PATCH 2/2] iio: imu: lsm6dsx: Add alternative ACPI mount matrix retrieval Samuel Dionne-Riel
2025-12-27 18:00 ` Jonathan Cameron
2025-12-28 17:21 ` Andy Shevchenko
2025-12-27 18:04 ` Jonathan Cameron [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251227180446.45836e37@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=nuno.sa@analog.com \
--cc=samuel@dionne-riel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®