[PATCH v1 0/6] misc: amd-sbi: Refactor SBTSI driver with I3C support and ioctl interface

[PATCH v1 0/6] misc: amd-sbi: Refactor SBTSI driver with I3C support and ioctl interface

[Akshay Gupta]

This series refactors the AMD SB-TSI (Side-Band Temperature Sensor
Interface) driver by moving it from the hwmon subsystem into the
drivers/misc/amd-sbi framework, alongside the existing SB-RMI driver.

Background:
The SB-TSI driver currently lives under drivers/hwmon/sbtsi_temp.c and
is limited to exposing temperature readings via the hwmon interface.
As AMD platforms evolve, SB-TSI access is required from multiple
consumers (hwmon, userspace via ioctl, I3C-attached devices), making
the hwmon-only placement insufficient.

This series restructures the driver into a layered design:

  - tsi-core.c  : core register access and ioctl/miscdevice support
  - tsi-hwmon.c : hwmon sensor layer built on top of the core
  - tsi.c       : I2C/I3C probe and glue

Changes in this series:
1. Move core SBTSI driver from drivers/hwmon into drivers/misc/amd-sbi,
   renaming sbtsi_temp.c -> sbtsi.c and wiring it into the amd-sbi
   Kconfig/Makefile. The hwmon probe entry point is preserved so
   existing device-tree bindings and hwmon consumers are unaffected.

2. Update the Kconfig entry to explicitly state that the driver targets
   BMC-side I2C/I3C controllers (ARM/ARM64), avoiding accidental
   enablement on non-BMC targets.

3. Split the hwmon sensor handling (sysfs attributes, hwmon_chip_info)
   into tsi-hwmon.c so the core transport layer is not entangled with
   hwmon internals, making future interface additions cleaner.

4. Extend the driver to support SB-TSI over I3C in addition to I2C.
   Both buses share the same core read/write path via sbtsi_xfer();
   the is_i3c flag selects the underlying transport at probe time.
   Backward compatibility with existing I2C deployments is maintained.

5. Add a miscdevice (/dev/sbtsi-<addr>) and an ioctl interface
   (SBTSI_IOCTL_REG_XFER_CMD) that allows root userspace to perform
   SB-TSI register read/write operations through the APML protocol,
   consistent with the existing SBRMI ioctl interface.

6. Document the new SBTSI miscdevice and its ioctl in
   Documentation/misc-devices/amd-sbi.rst.

Testing:
Tested on AMD Genoa/Turin/Venice BMC platforms with both I2C and I3C-attached
SB-TSI targets. hwmon sysfs attributes (tempX_input, tempX_max, etc.)
and ioctl register transfers verified against hardware.

Akshay Gupta (1):
  misc: amd-sbi: Update SBTSI Kconfig to clarify this is BMC driver

Prathima (5):
  hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
  misc: amd-sbi: Split SBTSI hwmon sensor handling into a separate
    entity
  misc: amd-sbi: Add support for SB-TSI over I3C
  misc: amd-sbi: Add SBTSI ioctl register transfer interface
  docs: misc: amd-sbi: Document SBTSI userspace interface

 Documentation/misc-devices/amd-sbi.rst |  18 ++
 drivers/hwmon/Kconfig                  |  10 -
 drivers/hwmon/Makefile                 |   1 -
 drivers/hwmon/sbtsi_temp.c             | 250 -------------------------
 drivers/misc/amd-sbi/Kconfig           |  24 +++
 drivers/misc/amd-sbi/Makefile          |   4 +
 drivers/misc/amd-sbi/tsi-core.c        | 146 +++++++++++++++
 drivers/misc/amd-sbi/tsi-core.h        |  44 +++++
 drivers/misc/amd-sbi/tsi-hwmon.c       | 198 ++++++++++++++++++++
 drivers/misc/amd-sbi/tsi.c             | 162 ++++++++++++++++
 include/uapi/misc/amd-apml.h           |  23 +++
 11 files changed, 619 insertions(+), 261 deletions(-)
 delete mode 100644 drivers/hwmon/sbtsi_temp.c
 create mode 100644 drivers/misc/amd-sbi/tsi-core.c
 create mode 100644 drivers/misc/amd-sbi/tsi-core.h
 create mode 100644 drivers/misc/amd-sbi/tsi-hwmon.c
 create mode 100644 drivers/misc/amd-sbi/tsi.c

-- 
2.34.1

[PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc

[Akshay Gupta]

From: Prathima <Prathima.Lk@amd.com>

Move SBTSI core functionality out of the hwmon-only path and into
drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.

This split prepares the driver for additional interfaces while keeping
hwmon support as an optional layer on top of common SBTSI core logic.

Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
 drivers/hwmon/Kconfig                                | 10 ----------
 drivers/hwmon/Makefile                               |  1 -
 drivers/misc/amd-sbi/Kconfig                         | 11 +++++++++++
 drivers/misc/amd-sbi/Makefile                        |  2 ++
 drivers/{hwmon/sbtsi_temp.c => misc/amd-sbi/sbtsi.c} |  2 +-
 5 files changed, 14 insertions(+), 12 deletions(-)
 rename drivers/{hwmon/sbtsi_temp.c => misc/amd-sbi/sbtsi.c} (98%)

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 328867242cb3..758f9c9f9e4f 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1936,16 +1936,6 @@ config SENSORS_SL28CPLD
 	  This driver can also be built as a module.  If so, the module
 	  will be called sl28cpld-hwmon.
 
-config SENSORS_SBTSI
-	tristate "Emulated SB-TSI temperature sensor"
-	depends on I2C
-	help
-	  If you say yes here you get support for emulated temperature
-	  sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
-
-	  This driver can also be built as a module. If so, the module will
-	  be called sbtsi_temp.
-
 config SENSORS_SHT15
 	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
 	depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5833c807c688..c9b6661cfc72 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -199,7 +199,6 @@ obj-$(CONFIG_SENSORS_PT5161L)	+= pt5161l.o
 obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
 obj-$(CONFIG_SENSORS_QNAP_MCU_HWMON)	+= qnap-mcu-hwmon.o
 obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
-obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
 obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
 obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig
index 30e7fad7356c..e6a422b4a371 100644
--- a/drivers/misc/amd-sbi/Kconfig
+++ b/drivers/misc/amd-sbi/Kconfig
@@ -20,3 +20,14 @@ config AMD_SBRMI_HWMON
 	  This provides support for RMI device hardware monitoring. If enabled,
 	  a hardware monitoring device will be created for each socket in
 	  the system.
+
+config SENSORS_SBTSI
+	tristate "Emulated SB-TSI temperature sensor"
+	depends on I2C
+	depends on HWMON
+	help
+	  If you say yes here you get support for emulated temperature
+	  sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called sbtsi.
diff --git a/drivers/misc/amd-sbi/Makefile b/drivers/misc/amd-sbi/Makefile
index 38eaaa651fd9..f04273c0d3ad 100644
--- a/drivers/misc/amd-sbi/Makefile
+++ b/drivers/misc/amd-sbi/Makefile
@@ -2,3 +2,5 @@
 sbrmi-i2c-objs  		+= rmi-i2c.o rmi-core.o
 sbrmi-i2c-$(CONFIG_AMD_SBRMI_HWMON)	+= rmi-hwmon.o
 obj-$(CONFIG_AMD_SBRMI_I2C)	+= sbrmi-i2c.o
+# SBTSI Configuration
+obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi.o
diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/misc/amd-sbi/sbtsi.c
similarity index 98%
rename from drivers/hwmon/sbtsi_temp.c
rename to drivers/misc/amd-sbi/sbtsi.c
index c5b2488c4c7f..e09b10c17771 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/misc/amd-sbi/sbtsi.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- * sbtsi_temp.c - hwmon driver for a SBI Temperature Sensor Interface (SB-TSI)
+ * sbtsi.c - hwmon driver for a SBI Temperature Sensor Interface (SB-TSI)
  *                compliant AMD SoC temperature device.
  *
  * Copyright (c) 2020, Google Inc.
-- 
2.34.1

Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc

[Guenter Roeck]

On 3/23/26 04:08, Akshay Gupta wrote:
> From: Prathima <Prathima.Lk@amd.com>
> 
> Move SBTSI core functionality out of the hwmon-only path and into
> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
> 
> This split prepares the driver for additional interfaces while keeping
> hwmon support as an optional layer on top of common SBTSI core logic.
> 

This moves the driver out of hwmon space into misc/amd-sbi which,
in my opinion, is completely unnecessary to accomplish the stated goals.

I assume this is to be able to make changes which do not follow
the hwmon ABI and/or to bypass hwmon subsystem review, similar
to what has been done by others.

Obviously, I think this is a bad idea. I won't give it a NACK,
but I won't approve (nor review) it either.

Guenter

Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc

[Gupta, Akshay]

On 3/23/2026 7:45 PM, Guenter Roeck wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 3/23/26 04:08, Akshay Gupta wrote:
>> From: Prathima <Prathima.Lk@amd.com>
>>
>> Move SBTSI core functionality out of the hwmon-only path and into
>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>
>> This split prepares the driver for additional interfaces while keeping
>> hwmon support as an optional layer on top of common SBTSI core logic.
>>
> This moves the driver out of hwmon space into misc/amd-sbi which,
> in my opinion, is completely unnecessary to accomplish the stated goals.
>
> I assume this is to be able to make changes which do not follow
> the hwmon ABI and/or to bypass hwmon subsystem review, similar
> to what has been done by others.
>
> Obviously, I think this is a bad idea. I won't give it a NACK,
> but I won't approve (nor review) it either.
>
> Guenter

Hi Guenter,

Thank you for your quick response.

At present, TSI supports a range of functionalities that cannot be 
exposed through hwmon. Additionally, a new protocol leveraging the TSI 
endpoint in hardware has been introduced, which, to our understanding, 
cannot be accommodated within the hwmon subsystem.

Since we already support the RMI interface via misc/amd-sbi, we believe 
this remains the appropriate place to continue AMD's out-of-band support.

I will update the commit message and cover letter to clearly articulate 
the rationale behind this change.

Thank you

Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc

[Guenter Roeck]

On 3/24/26 03:36, Gupta, Akshay wrote:
> 
> On 3/23/2026 7:45 PM, Guenter Roeck wrote:
>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>
>>
>> On 3/23/26 04:08, Akshay Gupta wrote:
>>> From: Prathima <Prathima.Lk@amd.com>
>>>
>>> Move SBTSI core functionality out of the hwmon-only path and into
>>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>>
>>> This split prepares the driver for additional interfaces while keeping
>>> hwmon support as an optional layer on top of common SBTSI core logic.
>>>
>> This moves the driver out of hwmon space into misc/amd-sbi which,
>> in my opinion, is completely unnecessary to accomplish the stated goals.
>>
>> I assume this is to be able to make changes which do not follow
>> the hwmon ABI and/or to bypass hwmon subsystem review, similar
>> to what has been done by others.
>>
>> Obviously, I think this is a bad idea. I won't give it a NACK,
>> but I won't approve (nor review) it either.
>>
>> Guenter
> 
> Hi Guenter,
> 
> Thank you for your quick response.
> 
> At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
> 
> Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
> 
> I will update the commit message and cover letter to clearly articulate the rationale behind this change.
> 
> Thank you
> 

That is neither a reason or an argument for moving _hwmon_ part of the code
out of the hwmon subsystem.

FWIW, your patch series removes a lot of error handling code. Sashiko has
a field day with it.

Guenter

Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc

[Gupta, Akshay]

On 3/24/2026 5:03 PM, Guenter Roeck wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 3/24/26 03:36, Gupta, Akshay wrote:
>> On 3/23/2026 7:45 PM, Guenter Roeck wrote:
>>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>>
>>>
>>> On 3/23/26 04:08, Akshay Gupta wrote:
>>>> From: Prathima <Prathima.Lk@amd.com>
>>>>
>>>> Move SBTSI core functionality out of the hwmon-only path and into
>>>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>>>
>>>> This split prepares the driver for additional interfaces while keeping
>>>> hwmon support as an optional layer on top of common SBTSI core logic.
>>>>
>>> This moves the driver out of hwmon space into misc/amd-sbi which,
>>> in my opinion, is completely unnecessary to accomplish the stated goals.
>>>
>>> I assume this is to be able to make changes which do not follow
>>> the hwmon ABI and/or to bypass hwmon subsystem review, similar
>>> to what has been done by others.
>>>
>>> Obviously, I think this is a bad idea. I won't give it a NACK,
>>> but I won't approve (nor review) it either.
>>>
>>> Guenter
>> Hi Guenter,
>>
>> Thank you for your quick response.
>>
>> At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
>>
>> Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
>>
>> I will update the commit message and cover letter to clearly articulate the rationale behind this change.
>>
>> Thank you
>>
> That is neither a reason or an argument for moving _hwmon_ part of the code
> out of the hwmon subsystem.
Following feedback from the Greg and MFD subsystem maintainers, we 
introduced an sb-rmi driver under misc/ that calls 
devm_hwmon_device_register_with_info(). We are considering the same 
approach for the sb-tsi driver. Would you recommend a more suitable 
alternative?
>
> FWIW, your patch series removes a lot of error handling code. Sashiko has
> a field day with it.
>
> Guenter
Thank you for the feedback. I will review and address this in the next 
version.
>

Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc

[Guenter Roeck]

On 3/26/26 22:07, Gupta, Akshay wrote:
> 
> On 3/24/2026 5:03 PM, Guenter Roeck wrote:
>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>
>>
>> On 3/24/26 03:36, Gupta, Akshay wrote:
>>> On 3/23/2026 7:45 PM, Guenter Roeck wrote:
>>>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>>>
>>>>
>>>> On 3/23/26 04:08, Akshay Gupta wrote:
>>>>> From: Prathima <Prathima.Lk@amd.com>
>>>>>
>>>>> Move SBTSI core functionality out of the hwmon-only path and into
>>>>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>>>>
>>>>> This split prepares the driver for additional interfaces while keeping
>>>>> hwmon support as an optional layer on top of common SBTSI core logic.
>>>>>
>>>> This moves the driver out of hwmon space into misc/amd-sbi which,
>>>> in my opinion, is completely unnecessary to accomplish the stated goals.
>>>>
>>>> I assume this is to be able to make changes which do not follow
>>>> the hwmon ABI and/or to bypass hwmon subsystem review, similar
>>>> to what has been done by others.
>>>>
>>>> Obviously, I think this is a bad idea. I won't give it a NACK,
>>>> but I won't approve (nor review) it either.
>>>>
>>>> Guenter
>>> Hi Guenter,
>>>
>>> Thank you for your quick response.
>>>
>>> At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
>>>
>>> Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
>>>
>>> I will update the commit message and cover letter to clearly articulate the rationale behind this change.
>>>
>>> Thank you
>>>
>> That is neither a reason or an argument for moving _hwmon_ part of the code
>> out of the hwmon subsystem.
> Following feedback from the Greg and MFD subsystem maintainers, we introduced an sb-rmi driver under misc/ that calls devm_hwmon_device_register_with_info(). We are considering the same approach for the sb-tsi driver. Would you recommend a more suitable alternative?

I would have suggested to use an auxiliary driver, similar to PECI,
but who am I to argue if senior maintainers suggest otherwise.

Guenter

Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc

[gregkh]

On Thu, Mar 26, 2026 at 10:52:29PM -0700, Guenter Roeck wrote:
> On 3/26/26 22:07, Gupta, Akshay wrote:
> > 
> > On 3/24/2026 5:03 PM, Guenter Roeck wrote:
> > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > > 
> > > 
> > > On 3/24/26 03:36, Gupta, Akshay wrote:
> > > > On 3/23/2026 7:45 PM, Guenter Roeck wrote:
> > > > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > > > > 
> > > > > 
> > > > > On 3/23/26 04:08, Akshay Gupta wrote:
> > > > > > From: Prathima <Prathima.Lk@amd.com>
> > > > > > 
> > > > > > Move SBTSI core functionality out of the hwmon-only path and into
> > > > > > drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
> > > > > > 
> > > > > > This split prepares the driver for additional interfaces while keeping
> > > > > > hwmon support as an optional layer on top of common SBTSI core logic.
> > > > > > 
> > > > > This moves the driver out of hwmon space into misc/amd-sbi which,
> > > > > in my opinion, is completely unnecessary to accomplish the stated goals.
> > > > > 
> > > > > I assume this is to be able to make changes which do not follow
> > > > > the hwmon ABI and/or to bypass hwmon subsystem review, similar
> > > > > to what has been done by others.
> > > > > 
> > > > > Obviously, I think this is a bad idea. I won't give it a NACK,
> > > > > but I won't approve (nor review) it either.
> > > > > 
> > > > > Guenter
> > > > Hi Guenter,
> > > > 
> > > > Thank you for your quick response.
> > > > 
> > > > At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
> > > > 
> > > > Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
> > > > 
> > > > I will update the commit message and cover letter to clearly articulate the rationale behind this change.
> > > > 
> > > > Thank you
> > > > 
> > > That is neither a reason or an argument for moving _hwmon_ part of the code
> > > out of the hwmon subsystem.
> > Following feedback from the Greg and MFD subsystem maintainers, we introduced an sb-rmi driver under misc/ that calls devm_hwmon_device_register_with_info(). We are considering the same approach for the sb-tsi driver. Would you recommend a more suitable alternative?
> 
> I would have suggested to use an auxiliary driver, similar to PECI,
> but who am I to argue if senior maintainers suggest otherwise.

Sounds like an aux driver makes sense to me too, I don't remember saying
that you HAD to call devm_hwmon_device_register_with_info(), where was
that stated in previous reviews?

thanks,

greg k-h

[PATCH v1 2/6] misc: amd-sbi: Update SBTSI Kconfig to clarify this is BMC driver

[Akshay Gupta]

Add an architecture dependency to the SBTSI Kconfig
This limits enablement to supported targets

Also clarify in the help text that the SBTSI driver is
intended to run on the BMC, not on the managed host node.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
---
 drivers/misc/amd-sbi/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig
index e6a422b4a371..19a8d596e8f5 100644
--- a/drivers/misc/amd-sbi/Kconfig
+++ b/drivers/misc/amd-sbi/Kconfig
@@ -24,10 +24,12 @@ config AMD_SBRMI_HWMON
 config SENSORS_SBTSI
 	tristate "Emulated SB-TSI temperature sensor"
 	depends on I2C
+	depends on ARM || ARM64 || COMPILE_TEST
 	depends on HWMON
 	help
 	  If you say yes here you get support for emulated temperature
 	  sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
+	  This driver is intended to run on the BMC, not the managed node.
 
 	  This driver can also be built as a module. If so, the module will
 	  be called sbtsi.
-- 
2.34.1

[PATCH v1 3/6] misc: amd-sbi: Split SBTSI hwmon sensor handling into a separate entity

[Akshay Gupta]

From: Prathima <Prathima.Lk@amd.com>

Separate SBTSI hwmon sensor handling from the core path to improve
code organization and maintainability.

This keeps core transport/register access independent while preserving
existing hwmon functionality through a dedicated hwmon component.

Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
 drivers/misc/amd-sbi/Kconfig                  |  12 +-
 drivers/misc/amd-sbi/Makefile                 |   2 +
 drivers/misc/amd-sbi/tsi-core.h               |  30 +++++
 drivers/misc/amd-sbi/{sbtsi.c => tsi-hwmon.c} | 120 ++++--------------
 drivers/misc/amd-sbi/tsi.c                    |  77 +++++++++++
 5 files changed, 142 insertions(+), 99 deletions(-)
 create mode 100644 drivers/misc/amd-sbi/tsi-core.h
 rename drivers/misc/amd-sbi/{sbtsi.c => tsi-hwmon.c} (57%)
 create mode 100644 drivers/misc/amd-sbi/tsi.c

diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig
index 19a8d596e8f5..2710860a86c7 100644
--- a/drivers/misc/amd-sbi/Kconfig
+++ b/drivers/misc/amd-sbi/Kconfig
@@ -25,7 +25,6 @@ config SENSORS_SBTSI
 	tristate "Emulated SB-TSI temperature sensor"
 	depends on I2C
 	depends on ARM || ARM64 || COMPILE_TEST
-	depends on HWMON
 	help
 	  If you say yes here you get support for emulated temperature
 	  sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
@@ -33,3 +32,14 @@ config SENSORS_SBTSI
 
 	  This driver can also be built as a module. If so, the module will
 	  be called sbtsi.
+
+config AMD_SBTSI_HWMON
+	bool "SBTSI hardware monitoring for AMD platforms"
+	depends on SENSORS_SBTSI && HWMON
+	depends on !(SENSORS_SBTSI=y && HWMON=m)
+	default y
+	help
+	  This provides support for TSI device hardware monitoring.
+	  When enabled, a hwmon device is created for each socket to expose
+	  temperature monitoring data through the standard Linux
+	  hwmon interface.
diff --git a/drivers/misc/amd-sbi/Makefile b/drivers/misc/amd-sbi/Makefile
index f04273c0d3ad..a874136e438f 100644
--- a/drivers/misc/amd-sbi/Makefile
+++ b/drivers/misc/amd-sbi/Makefile
@@ -3,4 +3,6 @@ sbrmi-i2c-objs  		+= rmi-i2c.o rmi-core.o
 sbrmi-i2c-$(CONFIG_AMD_SBRMI_HWMON)	+= rmi-hwmon.o
 obj-$(CONFIG_AMD_SBRMI_I2C)	+= sbrmi-i2c.o
 # SBTSI Configuration
+sbtsi-objs	+= tsi.o
+sbtsi-$(CONFIG_AMD_SBTSI_HWMON)	+= tsi-hwmon.o
 obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi.o
diff --git a/drivers/misc/amd-sbi/tsi-core.h b/drivers/misc/amd-sbi/tsi-core.h
new file mode 100644
index 000000000000..e60cf25fda7a
--- /dev/null
+++ b/drivers/misc/amd-sbi/tsi-core.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ */
+
+#ifndef _TSI_CORE_H_
+#define _TSI_CORE_H_
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+/* Each client has this additional data */
+struct sbtsi_data {
+	struct i2c_client *client;
+	bool ext_range_mode;
+	bool read_order;
+};
+
+#ifdef CONFIG_AMD_SBTSI_HWMON
+int create_sbtsi_hwmon_sensor_device(struct device *dev, struct sbtsi_data *data);
+#else
+static inline int create_sbtsi_hwmon_sensor_device(struct device *dev, struct sbtsi_data *data)
+{
+	return 0;
+}
+#endif
+#endif /*_TSI_CORE_H_*/
diff --git a/drivers/misc/amd-sbi/sbtsi.c b/drivers/misc/amd-sbi/tsi-hwmon.c
similarity index 57%
rename from drivers/misc/amd-sbi/sbtsi.c
rename to drivers/misc/amd-sbi/tsi-hwmon.c
index e09b10c17771..efd450a85d34 100644
--- a/drivers/misc/amd-sbi/sbtsi.c
+++ b/drivers/misc/amd-sbi/tsi-hwmon.c
@@ -1,59 +1,31 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- * sbtsi.c - hwmon driver for a SBI Temperature Sensor Interface (SB-TSI)
- *                compliant AMD SoC temperature device.
+ * tsi-hwmon.c - hwmon sensor support for side band TSI
  *
  * Copyright (c) 2020, Google Inc.
  * Copyright (c) 2020, Kun Yi <kunyi@google.com>
  */
 
-#include <linux/err.h>
-#include <linux/i2c.h>
-#include <linux/init.h>
 #include <linux/hwmon.h>
-#include <linux/module.h>
-#include <linux/of.h>
-#include <linux/bitfield.h>
+#include "tsi-core.h"
 
 /*
  * SB-TSI registers only support SMBus byte data access. "_INT" registers are
  * the integer part of a temperature value or limit, and "_DEC" registers are
  * corresponding decimal parts.
  */
-#define SBTSI_REG_TEMP_INT		0x01 /* RO */
-#define SBTSI_REG_STATUS		0x02 /* RO */
-#define SBTSI_REG_CONFIG		0x03 /* RO */
-#define SBTSI_REG_TEMP_HIGH_INT		0x07 /* RW */
-#define SBTSI_REG_TEMP_LOW_INT		0x08 /* RW */
-#define SBTSI_REG_TEMP_DEC		0x10 /* RW */
-#define SBTSI_REG_TEMP_HIGH_DEC		0x13 /* RW */
-#define SBTSI_REG_TEMP_LOW_DEC		0x14 /* RW */
+#define SBTSI_REG_TEMP_INT             0x01 /* RO */
+#define SBTSI_REG_STATUS               0x02 /* RO */
+#define SBTSI_REG_TEMP_HIGH_INT                0x07 /* RW */
+#define SBTSI_REG_TEMP_LOW_INT         0x08 /* RW */
+#define SBTSI_REG_TEMP_DEC             0x10 /* RW */
+#define SBTSI_REG_TEMP_HIGH_DEC                0x13 /* RW */
+#define SBTSI_REG_TEMP_LOW_DEC         0x14 /* RW */
 
-/*
- * Bit for reporting value with temperature measurement range.
- * bit == 0: Use default temperature range (0C to 255.875C).
- * bit == 1: Use extended temperature range (-49C to +206.875C).
- */
-#define SBTSI_CONFIG_EXT_RANGE_SHIFT	2
-/*
- * ReadOrder bit specifies the reading order of integer and decimal part of
- * CPU temperature for atomic reads. If bit == 0, reading integer part triggers
- * latching of the decimal part, so integer part should be read first.
- * If bit == 1, read order should be reversed.
- */
-#define SBTSI_CONFIG_READ_ORDER_SHIFT	5
-
-#define SBTSI_TEMP_EXT_RANGE_ADJ	49000
-
-#define SBTSI_TEMP_MIN	0
-#define SBTSI_TEMP_MAX	255875
+#define SBTSI_TEMP_EXT_RANGE_ADJ       49000
 
-/* Each client has this additional data */
-struct sbtsi_data {
-	struct i2c_client *client;
-	bool ext_range_mode;
-	bool read_order;
-};
+#define SBTSI_TEMP_MIN 0
+#define SBTSI_TEMP_MAX 255875
 
 /*
  * From SB-TSI spec: CPU temperature readings and limit registers encode the
@@ -85,7 +57,7 @@ static inline void sbtsi_mc_to_reg(s32 temp, u8 *integer, u8 *decimal)
 }
 
 static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
-		      u32 attr, int channel, long *val)
+		u32 attr, int channel, long *val)
 {
 	struct sbtsi_data *data = dev_get_drvdata(dev);
 	s32 temp_int, temp_dec;
@@ -112,12 +84,6 @@ static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
 		return -EINVAL;
 	}
 
-
-	if (temp_int < 0)
-		return temp_int;
-	if (temp_dec < 0)
-		return temp_dec;
-
 	*val = sbtsi_reg_to_mc(temp_int, temp_dec);
 	if (data->ext_range_mode)
 		*val -= SBTSI_TEMP_EXT_RANGE_ADJ;
@@ -126,7 +92,7 @@ static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
 }
 
 static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type,
-		       u32 attr, int channel, long val)
+		u32 attr, int channel, long val)
 {
 	struct sbtsi_data *data = dev_get_drvdata(dev);
 	int reg_int, reg_dec, err;
@@ -154,12 +120,15 @@ static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type,
 	if (err)
 		return err;
 
-	return i2c_smbus_write_byte_data(data->client, reg_dec, temp_dec);
+	err = i2c_smbus_write_byte_data(data->client, reg_dec, temp_dec);
+	if (err)
+		return err;
+	return 0;
 }
 
 static umode_t sbtsi_is_visible(const void *data,
-				enum hwmon_sensor_types type,
-				u32 attr, int channel)
+		enum hwmon_sensor_types type,
+		u32 attr, int channel)
 {
 	switch (type) {
 	case hwmon_temp:
@@ -195,56 +164,11 @@ static const struct hwmon_chip_info sbtsi_chip_info = {
 	.info = sbtsi_info,
 };
 
-static int sbtsi_probe(struct i2c_client *client)
+int create_sbtsi_hwmon_sensor_device(struct device *dev, struct sbtsi_data *data)
 {
-	struct device *dev = &client->dev;
 	struct device *hwmon_dev;
-	struct sbtsi_data *data;
-	int err;
 
-	data = devm_kzalloc(dev, sizeof(struct sbtsi_data), GFP_KERNEL);
-	if (!data)
-		return -ENOMEM;
-
-	data->client = client;
-
-	err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
-	if (err < 0)
-		return err;
-	data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), err);
-	data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
-
-	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+	hwmon_dev = devm_hwmon_device_register_with_info(dev, "sbtsi", data,
 							 &sbtsi_chip_info, NULL);
-
 	return PTR_ERR_OR_ZERO(hwmon_dev);
 }
-
-static const struct i2c_device_id sbtsi_id[] = {
-	{"sbtsi"},
-	{}
-};
-MODULE_DEVICE_TABLE(i2c, sbtsi_id);
-
-static const struct of_device_id __maybe_unused sbtsi_of_match[] = {
-	{
-		.compatible = "amd,sbtsi",
-	},
-	{ },
-};
-MODULE_DEVICE_TABLE(of, sbtsi_of_match);
-
-static struct i2c_driver sbtsi_driver = {
-	.driver = {
-		.name = "sbtsi",
-		.of_match_table = of_match_ptr(sbtsi_of_match),
-	},
-	.probe = sbtsi_probe,
-	.id_table = sbtsi_id,
-};
-
-module_i2c_driver(sbtsi_driver);
-
-MODULE_AUTHOR("Kun Yi <kunyi@google.com>");
-MODULE_DESCRIPTION("Hwmon driver for AMD SB-TSI emulated sensor");
-MODULE_LICENSE("GPL");
diff --git a/drivers/misc/amd-sbi/tsi.c b/drivers/misc/amd-sbi/tsi.c
new file mode 100644
index 000000000000..df754e60d84b
--- /dev/null
+++ b/drivers/misc/amd-sbi/tsi.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * tsi.c - Side band TSI over I2C support for AMD out of band management.
+ *
+ * Copyright (c) 2020-2026, Google Inc.
+ * Copyright (c) 2020-2026, Kun Yi <kunyi@google.com>
+ */
+
+#include <linux/bitfield.h>
+#include "tsi-core.h"
+
+#define SBTSI_REG_CONFIG		0x03 /* RO */
+
+/*
+ * Bit for reporting value with temperature measurement range.
+ * bit == 0: Use default temperature range (0C to 255.875C).
+ * bit == 1: Use extended temperature range (-49C to +206.875C).
+ */
+#define SBTSI_CONFIG_EXT_RANGE_SHIFT   2
+
+/*
+ * ReadOrder bit specifies the reading order of integer and decimal part of
+ * CPU temperature for atomic reads. If bit == 0, reading integer part triggers
+ * latching of the decimal part, so integer part should be read first.
+ */
+
+#define SBTSI_CONFIG_READ_ORDER_SHIFT  5
+
+static int sbtsi_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct sbtsi_data *data;
+	int err;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->client = client;
+	err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
+	if (err < 0)
+		return err;
+	data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), err);
+	data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
+
+	dev_set_drvdata(dev, data);
+	return create_sbtsi_hwmon_sensor_device(dev, data);
+}
+
+static const struct i2c_device_id sbtsi_id[] = {
+	{"sbtsi"},
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, sbtsi_id);
+
+static const struct of_device_id __maybe_unused sbtsi_of_match[] = {
+	{
+		.compatible = "amd,sbtsi",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, sbtsi_of_match);
+
+static struct i2c_driver sbtsi_driver = {
+	.driver = {
+		.name = "sbtsi",
+		.of_match_table = of_match_ptr(sbtsi_of_match),
+	},
+	.probe = sbtsi_probe,
+	.id_table = sbtsi_id,
+};
+
+module_i2c_driver(sbtsi_driver);
+
+MODULE_AUTHOR("Kun Yi <kunyi@google.com>");
+MODULE_DESCRIPTION("Hwmon driver for AMD SB-TSI emulated sensor");
+MODULE_LICENSE("GPL");
-- 
2.34.1

[PATCH v1 4/6] misc: amd-sbi: Add support for SB-TSI over I3C

[Akshay Gupta]

From: Prathima <Prathima.Lk@amd.com>

- Extend the SB-TSI driver to support both I2C and I3C bus interfaces.
- The driver maintains backward compatibility with existing I2C
deployments while enabling support for systems using the I3C bus.

Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
 drivers/misc/amd-sbi/Kconfig     |  5 ++-
 drivers/misc/amd-sbi/Makefile    |  2 +-
 drivers/misc/amd-sbi/tsi-core.c  | 64 ++++++++++++++++++++++++++++++++
 drivers/misc/amd-sbi/tsi-core.h  | 11 +++++-
 drivers/misc/amd-sbi/tsi-hwmon.c | 50 ++++++++++++++++++-------
 drivers/misc/amd-sbi/tsi.c       | 62 +++++++++++++++++++++++++++++--
 6 files changed, 173 insertions(+), 21 deletions(-)
 create mode 100644 drivers/misc/amd-sbi/tsi-core.c

diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig
index 2710860a86c7..d18652537788 100644
--- a/drivers/misc/amd-sbi/Kconfig
+++ b/drivers/misc/amd-sbi/Kconfig
@@ -23,11 +23,12 @@ config AMD_SBRMI_HWMON
 
 config SENSORS_SBTSI
 	tristate "Emulated SB-TSI temperature sensor"
-	depends on I2C
+	depends on I3C_OR_I2C
 	depends on ARM || ARM64 || COMPILE_TEST
 	help
 	  If you say yes here you get support for emulated temperature
-	  sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
+	  sensors on AMD SoCs with SB-TSI interface connected to a BMC device
+	  over I2C and I3C.
 	  This driver is intended to run on the BMC, not the managed node.
 
 	  This driver can also be built as a module. If so, the module will
diff --git a/drivers/misc/amd-sbi/Makefile b/drivers/misc/amd-sbi/Makefile
index a874136e438f..e87c8e618dcc 100644
--- a/drivers/misc/amd-sbi/Makefile
+++ b/drivers/misc/amd-sbi/Makefile
@@ -3,6 +3,6 @@ sbrmi-i2c-objs  		+= rmi-i2c.o rmi-core.o
 sbrmi-i2c-$(CONFIG_AMD_SBRMI_HWMON)	+= rmi-hwmon.o
 obj-$(CONFIG_AMD_SBRMI_I2C)	+= sbrmi-i2c.o
 # SBTSI Configuration
-sbtsi-objs	+= tsi.o
+sbtsi-objs	+= tsi.o tsi-core.o
 sbtsi-$(CONFIG_AMD_SBTSI_HWMON)	+= tsi-hwmon.o
 obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi.o
diff --git a/drivers/misc/amd-sbi/tsi-core.c b/drivers/misc/amd-sbi/tsi-core.c
new file mode 100644
index 000000000000..fcb7fcf87a55
--- /dev/null
+++ b/drivers/misc/amd-sbi/tsi-core.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * tsi-core.c - file defining SB-TSI protocols compliant
+ *              AMD SoC device.
+ * Copyright (c) 2020, Google Inc.
+ * Copyright (c) 2020, Kun Yi <kunyi@google.com>
+ */
+
+#include "tsi-core.h"
+
+/* I3C read transfer function */
+static int sbtsi_i3c_read(struct sbtsi_data *data, u8 reg, u8 *val)
+{
+	struct i3c_xfer xfers[2];
+
+	/* Send register address */
+	xfers[0].rnw = false;
+	xfers[0].len = 1;
+	xfers[0].data.out = &reg;
+
+	/* Read data */
+	xfers[1].rnw = true;
+	xfers[1].len = 1;
+	xfers[1].data.in = val;
+
+	return i3c_device_do_xfers(data->i3cdev, xfers, 2, I3C_SDR);
+}
+
+/* I3C write transfer function */
+static int sbtsi_i3c_write(struct sbtsi_data *data, u8 reg, u8 *val)
+{
+	u8 buf[2] = { reg, *val };
+	struct i3c_xfer xfers = {
+		.rnw = false,
+		.len = 2,
+		.data.out = buf,
+	};
+
+	return i3c_device_do_xfers(data->i3cdev, &xfers, 1, I3C_SDR);
+}
+
+/* I2C transfer function */
+static int sbtsi_i2c_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
+{
+	if (is_read) {
+		int ret = i2c_smbus_read_byte_data(data->client, reg);
+
+		if (ret < 0)
+			return ret;
+		*val = ret;
+		return 0;
+	}
+	return i2c_smbus_write_byte_data(data->client, reg, *val);
+}
+
+/* Unified transfer function for I2C and I3C access */
+int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
+{
+	if (data->is_i3c)
+		return is_read ? sbtsi_i3c_read(data, reg, val)
+			: sbtsi_i3c_write(data, reg, val);
+
+	return sbtsi_i2c_xfer(data, reg, val, is_read);
+}
diff --git a/drivers/misc/amd-sbi/tsi-core.h b/drivers/misc/amd-sbi/tsi-core.h
index e60cf25fda7a..a4ded17942c9 100644
--- a/drivers/misc/amd-sbi/tsi-core.h
+++ b/drivers/misc/amd-sbi/tsi-core.h
@@ -11,14 +11,23 @@
 #include <linux/init.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/types.h>
+#include <linux/i3c/device.h>
+#include <linux/i3c/master.h>
 
 /* Each client has this additional data */
 struct sbtsi_data {
-	struct i2c_client *client;
+	union {
+		struct i2c_client *client;
+		struct i3c_device *i3cdev;
+	};
 	bool ext_range_mode;
 	bool read_order;
+	bool is_i3c;
 };
 
+int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read);
+
 #ifdef CONFIG_AMD_SBTSI_HWMON
 int create_sbtsi_hwmon_sensor_device(struct device *dev, struct sbtsi_data *data);
 #else
diff --git a/drivers/misc/amd-sbi/tsi-hwmon.c b/drivers/misc/amd-sbi/tsi-hwmon.c
index efd450a85d34..9b447042d4aa 100644
--- a/drivers/misc/amd-sbi/tsi-hwmon.c
+++ b/drivers/misc/amd-sbi/tsi-hwmon.c
@@ -27,8 +27,7 @@
 #define SBTSI_TEMP_MIN 0
 #define SBTSI_TEMP_MAX 255875
 
-/*
- * From SB-TSI spec: CPU temperature readings and limit registers encode the
+/* From SB-TSI spec: CPU temperature readings and limit registers encode the
  * temperature in increments of 0.125 from 0 to 255.875. The "high byte"
  * register encodes the base-2 of the integer portion, and the upper 3 bits of
  * the "low byte" encode in base-2 the decimal portion.
@@ -61,24 +60,50 @@ static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
 {
 	struct sbtsi_data *data = dev_get_drvdata(dev);
 	s32 temp_int, temp_dec;
+	u8 reg_val;
+	int err;
 
 	switch (attr) {
 	case hwmon_temp_input:
 		if (data->read_order) {
-			temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_DEC);
-			temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_INT);
+			err = sbtsi_xfer(data, SBTSI_REG_TEMP_DEC, &reg_val, true);
+			if (err < 0)
+				return err;
+			temp_dec = reg_val;
+			err = sbtsi_xfer(data, SBTSI_REG_TEMP_INT, &reg_val, true);
+			if (err < 0)
+				return err;
+			temp_int = reg_val;
 		} else {
-			temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_INT);
-			temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_DEC);
+			err = sbtsi_xfer(data, SBTSI_REG_TEMP_INT, &reg_val, true);
+			if (err < 0)
+				return err;
+			temp_int = reg_val;
+			err = sbtsi_xfer(data, SBTSI_REG_TEMP_DEC, &reg_val, true);
+			if (err < 0)
+				return err;
+			temp_dec = reg_val;
 		}
 		break;
 	case hwmon_temp_max:
-		temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_HIGH_INT);
-		temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_HIGH_DEC);
+		err = sbtsi_xfer(data, SBTSI_REG_TEMP_HIGH_INT, &reg_val, true);
+		if (err < 0)
+			return err;
+		temp_int = reg_val;
+		err = sbtsi_xfer(data, SBTSI_REG_TEMP_HIGH_DEC, &reg_val, true);
+		if (err < 0)
+			return err;
+		temp_dec = reg_val;
 		break;
 	case hwmon_temp_min:
-		temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_LOW_INT);
-		temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_LOW_DEC);
+		err = sbtsi_xfer(data, SBTSI_REG_TEMP_LOW_INT, &reg_val, true);
+		if (err < 0)
+			return err;
+		temp_int = reg_val;
+		err = sbtsi_xfer(data, SBTSI_REG_TEMP_LOW_DEC, &reg_val, true);
+		if (err < 0)
+			return err;
+		temp_dec = reg_val;
 		break;
 	default:
 		return -EINVAL;
@@ -115,12 +140,11 @@ static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type,
 		val += SBTSI_TEMP_EXT_RANGE_ADJ;
 	val = clamp_val(val, SBTSI_TEMP_MIN, SBTSI_TEMP_MAX);
 	sbtsi_mc_to_reg(val, &temp_int, &temp_dec);
-
-	err = i2c_smbus_write_byte_data(data->client, reg_int, temp_int);
+	err = sbtsi_xfer(data, reg_int, &temp_int, false);
 	if (err)
 		return err;
 
-	err = i2c_smbus_write_byte_data(data->client, reg_dec, temp_dec);
+	err = sbtsi_xfer(data, reg_dec, &temp_dec, false);
 	if (err)
 		return err;
 	return 0;
diff --git a/drivers/misc/amd-sbi/tsi.c b/drivers/misc/amd-sbi/tsi.c
index df754e60d84b..d7a8237fc4fd 100644
--- a/drivers/misc/amd-sbi/tsi.c
+++ b/drivers/misc/amd-sbi/tsi.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- * tsi.c - Side band TSI over I2C support for AMD out of band management.
+ * tsi.c - Side band TSI over I2C/I3C support for AMD out of band management.
  *
  * Copyright (c) 2020-2026, Google Inc.
  * Copyright (c) 2020-2026, Kun Yi <kunyi@google.com>
@@ -26,7 +26,7 @@
 
 #define SBTSI_CONFIG_READ_ORDER_SHIFT  5
 
-static int sbtsi_probe(struct i2c_client *client)
+static int sbtsi_i2c_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
 	struct sbtsi_data *data;
@@ -36,6 +36,7 @@ static int sbtsi_probe(struct i2c_client *client)
 	if (!data)
 		return -ENOMEM;
 
+	data->is_i3c = false;
 	data->client = client;
 	err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
 	if (err < 0)
@@ -66,11 +67,64 @@ static struct i2c_driver sbtsi_driver = {
 		.name = "sbtsi",
 		.of_match_table = of_match_ptr(sbtsi_of_match),
 	},
-	.probe = sbtsi_probe,
+	.probe = sbtsi_i2c_probe,
 	.id_table = sbtsi_id,
 };
 
-module_i2c_driver(sbtsi_driver);
+static int sbtsi_i3c_probe(struct i3c_device *i3cdev)
+{
+	struct device *dev = i3cdev_to_dev(i3cdev);
+	struct sbtsi_data *data;
+	int err;
+	u8 val;
+	/*
+	 * AMD OOB devices differ on basis of Instance ID,
+	 * for SBTSI, instance ID is 0.
+	 * As the device Id match is not on basis of Instance ID,
+	 * add the below check to probe the SBTSI device only and
+	 * not other OOB devices.
+	 */
+	if (I3C_PID_INSTANCE_ID(i3cdev->desc->info.pid) != 0)
+		return -ENXIO;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->i3cdev = i3cdev;
+	data->is_i3c = true;
+
+	err = sbtsi_xfer(data, SBTSI_REG_CONFIG, &val, true);
+	if (err)
+		return err;
+
+	data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), val);
+	data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), val);
+
+	dev_set_drvdata(dev, data);
+	return create_sbtsi_hwmon_sensor_device(dev, data);
+}
+
+static const struct i3c_device_id sbtsi_i3c_id[] = {
+	/* PID for AMD SBTSI device */
+	I3C_DEVICE_EXTRA_INFO(0x112, 0x0, 0x1, NULL),
+	I3C_DEVICE_EXTRA_INFO(0x0, 0x0, 0x118, NULL), /* Socket:0, Venice A0 */
+	I3C_DEVICE_EXTRA_INFO(0x0, 0x100, 0x118, NULL), /* Socket:1, Venice A0 */
+	I3C_DEVICE_EXTRA_INFO(0x112, 0x0, 0x119, NULL), /* Socket:0, Venice B0 */
+	I3C_DEVICE_EXTRA_INFO(0x112, 0x100, 0x119, NULL), /* Socket:1, Venice B0 */
+	{}
+};
+MODULE_DEVICE_TABLE(i3c, sbtsi_i3c_id);
+
+static struct i3c_driver sbtsi_i3c_driver = {
+	.driver = {
+		.name = "sbtsi-i3c",
+	},
+	.probe = sbtsi_i3c_probe,
+	.id_table = sbtsi_i3c_id,
+};
+
+module_i3c_i2c_driver(sbtsi_i3c_driver, &sbtsi_driver);
 
 MODULE_AUTHOR("Kun Yi <kunyi@google.com>");
 MODULE_DESCRIPTION("Hwmon driver for AMD SB-TSI emulated sensor");
-- 
2.34.1

[PATCH v1 5/6] misc: amd-sbi: Add SBTSI ioctl register transfer interface

[Akshay Gupta]

From: Prathima <Prathima.Lk@amd.com>

Implement IOCTL interface for SB-TSI driver to enable userspace access
to TSI register read/write operations through the AMD Advanced Platform
Management Link (APML) protocol.

Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
 drivers/misc/amd-sbi/tsi-core.c | 86 ++++++++++++++++++++++++++++++++-
 drivers/misc/amd-sbi/tsi-core.h |  5 ++
 drivers/misc/amd-sbi/tsi.c      | 37 ++++++++++++--
 include/uapi/misc/amd-apml.h    | 23 +++++++++
 4 files changed, 146 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/amd-sbi/tsi-core.c b/drivers/misc/amd-sbi/tsi-core.c
index fcb7fcf87a55..080cf1f368df 100644
--- a/drivers/misc/amd-sbi/tsi-core.c
+++ b/drivers/misc/amd-sbi/tsi-core.c
@@ -6,6 +6,10 @@
  * Copyright (c) 2020, Kun Yi <kunyi@google.com>
  */
 
+#include <linux/fs.h>
+#include <linux/ioctl.h>
+#include <linux/uaccess.h>
+#include <uapi/misc/amd-apml.h>
 #include "tsi-core.h"
 
 /* I3C read transfer function */
@@ -56,9 +60,87 @@ static int sbtsi_i2c_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read
 /* Unified transfer function for I2C and I3C access */
 int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
 {
+	int ret;
+
+	mutex_lock(&data->lock);
 	if (data->is_i3c)
-		return is_read ? sbtsi_i3c_read(data, reg, val)
+		ret = is_read ? sbtsi_i3c_read(data, reg, val)
 			: sbtsi_i3c_write(data, reg, val);
+	else
+		ret = sbtsi_i2c_xfer(data, reg, val, is_read);
+	mutex_unlock(&data->lock);
+	return ret;
+}
+
+static int apml_tsi_reg_xfer(struct sbtsi_data *data,
+			     struct apml_tsi_xfer_msg __user *arg)
+{
+	struct apml_tsi_xfer_msg msg = { 0 };
+	u8 val;
+	int ret;
+
+	/* Copy the structure from user */
+	if (copy_from_user(&msg, arg, sizeof(struct apml_tsi_xfer_msg)))
+		return -EFAULT;
+
+	if (msg.rflag) {
+		/* Read operation */
+		ret = sbtsi_xfer(data, msg.reg_addr, &val, true);
+		if (!ret)
+			msg.data_in_out = val;
+	} else {
+		/* Write operation */
+		ret = sbtsi_xfer(data, msg.reg_addr, &msg.data_in_out, false);
+	}
+
+	if (msg.rflag && !ret) {
+		if (copy_to_user(arg, &msg, sizeof(struct apml_tsi_xfer_msg)))
+			return -EFAULT;
+	}
+	return ret;
+}
+
+static long sbtsi_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
+{
+	void __user *argp = (void __user *)arg;
+	struct sbtsi_data *data;
+
+	data = container_of(fp->private_data, struct sbtsi_data, sbtsi_misc_dev);
+	switch (cmd) {
+	case SBTSI_IOCTL_REG_XFER_CMD:
+		return apml_tsi_reg_xfer(data, argp);
+	default:
+		return -ENOTTY;
+	}
+}
+
+static const struct file_operations sbtsi_fops = {
+	.owner          = THIS_MODULE,
+	.unlocked_ioctl = sbtsi_ioctl,
+	.compat_ioctl   = compat_ptr_ioctl,
+};
+
+int create_misc_tsi_device(struct sbtsi_data *data,
+			   struct device *dev)
+{
+	int ret;
+
+	data->sbtsi_misc_dev.name            = devm_kasprintf(dev, GFP_KERNEL,
+							      "sbtsi-%x", data->dev_addr);
+	if (!data->sbtsi_misc_dev.name)
+		return -ENOMEM;
+	data->sbtsi_misc_dev.minor           = MISC_DYNAMIC_MINOR;
+	data->sbtsi_misc_dev.fops            = &sbtsi_fops;
+	data->sbtsi_misc_dev.parent          = dev;
+	data->sbtsi_misc_dev.nodename        = devm_kasprintf(dev, GFP_KERNEL,
+							      "sbtsi-%x", data->dev_addr);
+	if (!data->sbtsi_misc_dev.nodename)
+		return -ENOMEM;
+	data->sbtsi_misc_dev.mode            = 0600;
+
+	ret = misc_register(&data->sbtsi_misc_dev);
+	if (ret)
+		return ret;
 
-	return sbtsi_i2c_xfer(data, reg, val, is_read);
+	return ret;
 }
diff --git a/drivers/misc/amd-sbi/tsi-core.h b/drivers/misc/amd-sbi/tsi-core.h
index a4ded17942c9..d130ceadde04 100644
--- a/drivers/misc/amd-sbi/tsi-core.h
+++ b/drivers/misc/amd-sbi/tsi-core.h
@@ -9,6 +9,7 @@
 #include <linux/err.h>
 #include <linux/i2c.h>
 #include <linux/init.h>
+#include <linux/miscdevice.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/types.h>
@@ -21,12 +22,16 @@ struct sbtsi_data {
 		struct i2c_client *client;
 		struct i3c_device *i3cdev;
 	};
+	struct miscdevice sbtsi_misc_dev;
+	struct mutex lock; /* serializes SBTSI register access */
 	bool ext_range_mode;
 	bool read_order;
 	bool is_i3c;
+	u8 dev_addr;
 };
 
 int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read);
+int create_misc_tsi_device(struct sbtsi_data *data, struct device *dev);
 
 #ifdef CONFIG_AMD_SBTSI_HWMON
 int create_sbtsi_hwmon_sensor_device(struct device *dev, struct sbtsi_data *data);
diff --git a/drivers/misc/amd-sbi/tsi.c b/drivers/misc/amd-sbi/tsi.c
index d7a8237fc4fd..6e321064a3f3 100644
--- a/drivers/misc/amd-sbi/tsi.c
+++ b/drivers/misc/amd-sbi/tsi.c
@@ -38,6 +38,7 @@ static int sbtsi_i2c_probe(struct i2c_client *client)
 
 	data->is_i3c = false;
 	data->client = client;
+	mutex_init(&data->lock);
 	err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
 	if (err < 0)
 		return err;
@@ -45,7 +46,21 @@ static int sbtsi_i2c_probe(struct i2c_client *client)
 	data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
 
 	dev_set_drvdata(dev, data);
-	return create_sbtsi_hwmon_sensor_device(dev, data);
+	err = create_sbtsi_hwmon_sensor_device(dev, data);
+	if (err < 0)
+		return err;
+	data->dev_addr = client->addr;
+	return create_misc_tsi_device(data, dev);
+}
+
+static void sbtsi_i2c_remove(struct i2c_client *client)
+{
+	struct sbtsi_data *data = dev_get_drvdata(&client->dev);
+
+	if (data)
+		misc_deregister(&data->sbtsi_misc_dev);
+
+	dev_info(&client->dev, "Removed sbtsi driver\n");
 }
 
 static const struct i2c_device_id sbtsi_id[] = {
@@ -68,6 +83,7 @@ static struct i2c_driver sbtsi_driver = {
 		.of_match_table = of_match_ptr(sbtsi_of_match),
 	},
 	.probe = sbtsi_i2c_probe,
+	.remove = sbtsi_i2c_remove,
 	.id_table = sbtsi_id,
 };
 
@@ -90,7 +106,7 @@ static int sbtsi_i3c_probe(struct i3c_device *i3cdev)
 	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
-
+	mutex_init(&data->lock);
 	data->i3cdev = i3cdev;
 	data->is_i3c = true;
 
@@ -102,7 +118,21 @@ static int sbtsi_i3c_probe(struct i3c_device *i3cdev)
 	data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), val);
 
 	dev_set_drvdata(dev, data);
-	return create_sbtsi_hwmon_sensor_device(dev, data);
+	err = create_sbtsi_hwmon_sensor_device(dev, data);
+	if (err < 0)
+		return err;
+	data->dev_addr = i3cdev->desc->info.dyn_addr;
+	return create_misc_tsi_device(data, dev);
+}
+
+static void sbtsi_i3c_remove(struct i3c_device *i3cdev)
+{
+	struct sbtsi_data *data = dev_get_drvdata(&i3cdev->dev);
+
+	if (data)
+		misc_deregister(&data->sbtsi_misc_dev);
+
+	dev_info(&i3cdev->dev, "Removed sbtsi-i3c driver\n");
 }
 
 static const struct i3c_device_id sbtsi_i3c_id[] = {
@@ -121,6 +151,7 @@ static struct i3c_driver sbtsi_i3c_driver = {
 		.name = "sbtsi-i3c",
 	},
 	.probe = sbtsi_i3c_probe,
+	.remove = sbtsi_i3c_remove,
 	.id_table = sbtsi_i3c_id,
 };
 
diff --git a/include/uapi/misc/amd-apml.h b/include/uapi/misc/amd-apml.h
index 745b3338fc06..199532b8e64a 100644
--- a/include/uapi/misc/amd-apml.h
+++ b/include/uapi/misc/amd-apml.h
@@ -73,6 +73,13 @@ struct apml_reg_xfer_msg {
 	__u8 rflag;
 };
 
+struct apml_tsi_xfer_msg {
+	__u8 reg_addr;	/* TSI register address offset */
+	__u8 data_in_out;	/* Register data for read/write */
+	__u8 rflag;	/* Register read or write */
+	__u8 pad;	/* Explicit padding */
+};
+
 /*
  * AMD sideband interface base IOCTL
  */
@@ -149,4 +156,20 @@ struct apml_reg_xfer_msg {
  */
 #define SBRMI_IOCTL_REG_XFER_CMD	_IOWR(SB_BASE_IOCTL_NR, 3, struct apml_reg_xfer_msg)
 
+/**
+ * DOC: SBTSI_IOCTL_REG_XFER_CMD
+ *
+ * @Parameters
+ *
+ * @struct apml_tsi_xfer_msg
+ *      Pointer to the &struct apml_tsi_xfer_msg that will contain the protocol
+ *      information
+ *
+ * @Description
+ * IOCTL command for APML TSI messages using generic _IOWR
+ * The IOCTL provides userspace access to AMD sideband TSI register xfer protocol
+ * - TSI protocol to read/write temperature sensor registers
+ */
+#define SBTSI_IOCTL_REG_XFER_CMD	_IOWR(SB_BASE_IOCTL_NR, 4, struct apml_tsi_xfer_msg)
+
 #endif /*_AMD_APML_H_*/
-- 
2.34.1

Re: [PATCH v1 5/6] misc: amd-sbi: Add SBTSI ioctl register transfer interface

[Greg KH]

On Mon, Mar 23, 2026 at 04:38:10PM +0530, Akshay Gupta wrote:
> +	dev_info(&client->dev, "Removed sbtsi driver\n");

When drivers work properly, they are quiet.  No need for this kernel log
spam.

And were are all of these new ioctls documented and where is the
userspace tools that use them?

thanks,

greg k-h

[PATCH v1 6/6] docs: misc: amd-sbi: Document SBTSI userspace interface

[Akshay Gupta]

From: Prathima <Prathima.Lk@amd.com>

- Document AMD sideband IOCTL description defined
  for SBTSI and its usage.
  User space C-APIs are made available by esmi_oob_library [1],
  which is provided by the E-SMS project [2].

  Link: https://github.com/amd/esmi_oob_library [1]
  Link: https://www.amd.com/en/developer/e-sms.html [2]

Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
 Documentation/misc-devices/amd-sbi.rst | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/misc-devices/amd-sbi.rst b/Documentation/misc-devices/amd-sbi.rst
index f91ddadefe48..ddff3cea8ed1 100644
--- a/Documentation/misc-devices/amd-sbi.rst
+++ b/Documentation/misc-devices/amd-sbi.rst
@@ -48,6 +48,20 @@ Access restrictions:
  * APML Mailbox messages and Register xfer access are read-write,
  * CPUID and MCA_MSR access is read-only.
 
+SBTSI device
+============
+
+apml_sbtsi driver under the drivers/misc/amd-sbi creates miscdevice
+/dev/sbtsi-* to let user space programs run APML TSI register xfer
+commands.
+
+The driver supports both I2C and I3C transports for SB-TSI targets.
+The transport is selected by the bus where the device is enumerated.
+
+Access restrictions:
+ * Only root user is allowed to open the file.
+ * APML TSI Register xfer access is read-write.
+
 Driver IOCTLs
 =============
 
@@ -63,6 +77,9 @@ Driver IOCTLs
 .. c:macro:: SBRMI_IOCTL_REG_XFER_CMD
 .. kernel-doc:: include/uapi/misc/amd-apml.h
    :doc: SBRMI_IOCTL_REG_XFER_CMD
+.. c:macro:: SBTSI_IOCTL_REG_XFER_CMD
+.. kernel-doc:: include/uapi/misc/amd-apml.h
+   :doc: SBTSI_IOCTL_REG_XFER_CMD
 
 User-space usage
 ================
@@ -92,6 +109,7 @@ The following IOCTLs are defined:
 ``#define SBRMI_IOCTL_CPUID_CMD		_IOWR(SB_BASE_IOCTL_NR, 1, struct apml_cpuid_msg)``
 ``#define SBRMI_IOCTL_MCAMSR_CMD	_IOWR(SB_BASE_IOCTL_NR, 2, struct apml_mcamsr_msg)``
 ``#define SBRMI_IOCTL_REG_XFER_CMD	_IOWR(SB_BASE_IOCTL_NR, 3, struct apml_reg_xfer_msg)``
+``#define SBTSI_IOCTL_REG_XFER_CMD      _IOWR(SB_BASE_IOCTL_NR, 4, struct apml_tsi_xfer_msg)``
 
 
 User space C-APIs are made available by esmi_oob_library, hosted at
-- 
2.34.1

Re: [PATCH v1 6/6] docs: misc: amd-sbi: Document SBTSI userspace interface

[Greg KH]

On Mon, Mar 23, 2026 at 04:38:11PM +0530, Akshay Gupta wrote:
> From: Prathima <Prathima.Lk@amd.com>
> 
> - Document AMD sideband IOCTL description defined
>   for SBTSI and its usage.
>   User space C-APIs are made available by esmi_oob_library [1],
>   which is provided by the E-SMS project [2].
> 
>   Link: https://github.com/amd/esmi_oob_library [1]
>   Link: https://www.amd.com/en/developer/e-sms.html [2]

Ok, nevermind, here's the documentation :)

But it's very tiny, it's not saying what the api actually is.

thanks,

greg k-h