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

["Gupta, Akshay" <Akshay.Gupta@amd.com>]

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.