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.1On 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
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
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
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. >
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
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
On 3/27/2026 12:53 PM, gregkh@linuxfoundation.org wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > 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 Thank you Greg and Guenter for the feedback. I will explore auxiliary driver and submit the changes as part of next version. This way hwmon sensor will remain in hwmon subsytem and new implementation can be part of misc. Following the discussions at https://lore.kernel.org/all/01c95139-dfeb-6983-77d2-4382ffb50896@amd.com/, https://lore.kernel.org/all/8aa17f38-a6f6-4ba9-b38c-767ed39c1c92@roeck-us.net/, we plan to adopt the same approach for the TSI driver.
© 2016 - 2026 Red Hat, Inc.