From: "Chatradhi, Naveen Krishna" <naveenkrishna.chatradhi@amd.com>
To: Lee Jones <lee@kernel.org>, Guenter Roeck <linux@roeck-us.net>
Cc: Naveen Krishna Chatradhi <nchatrad@amd.com>,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
Akshay Gupta <Akshay.Gupta@amd.com>,
arnd@arndb.de, gregkh@linuxfoundation.org
Subject: Re: [PATCH 2/2] sbrmi: Add support for APML protocols
Date: Wed, 15 May 2024 17:00:57 +0530 [thread overview]
Message-ID: <269884a8-da86-4cb5-b4eb-2827578608d4@amd.com> (raw)
In-Reply-To: <20240515103217.GA6035@google.com>
On 5/15/2024 4:02 PM, Lee Jones wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Tue, 14 May 2024, Guenter Roeck wrote:
>
>> On 5/14/24 12:15, Chatradhi, Naveen Krishna wrote:
>>> + @Misc and @MFD maintainers in CC
>>>
>>> Hi
>>>
>>> On 5/3/2024 3:56 AM, Guenter Roeck wrote:
>>>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>>>
>>>>
>>>> On 5/2/24 15:05, Naveen Krishna Chatradhi wrote:
>>>>> From: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
>>>>>
>>>>> The present sbrmi module only support reporting power. However, AMD data
>>>>> center processors support various system management functionality
>>>>> Out-of-band over Advanced Platform Management Link APML.
>>>>>
>>>>> Register a miscdevice, which creates a device /dev/sbrmiX with an IOCTL
>>>>> interface for the user space to invoke the following protocols.
>>>>> - Mailbox read/write (already defined in sbrmi_mailbox_xfer())
>>>>> - CPUID read
>>>>> - MCAMSR read
>>>>>
>>>> This is not hardware monitoring functionality and would have to reside
>>>> elsewhere, outside the hwmon subsystem.
>>> I thought as much, please provide your opinion on the following approach.
>>>
>>> Background: Present sbrmi under hwmon subsystem is probed as an i2c driver and reports power.
>>>
>>> However, APML interface defines few other protocols to support OOB system management functionality.
>>>
>>> As adding the core functionality of the APML interface in drivers/hwmon/sbrmi is not the correct approach.
>>>
>>> We would like do the following
>>>
>>> 1. Move the i2c client probe, misc device registration and rmi_mailbox_xfer() function to a drivers/misc.
>>>
>>> 2. Add an MFD device with a cell, which probes the hwmon/sbrmi and continues to report power using the symbols exported by the misc/sbrmi.
>>>
>> afaik mfd API function must not be used outside drivers/mfd. The mfd maintainer
>> is (or at least used to be) pretty strict on that. The core code of a
>> multi-function device might better be implemented in drivers/mfd, with
>> drivers in drivers/misc (for the misc device) and drivers/hwmon/ (for
>> hwmon functionality). The misc and hwmon drivers could then communicate
>> with the core using regmap.
Thanks Guenter, for the inputs.
> Yes, please only use the MFD API from drivers/mfd.
>
> There are 'offenders' that slipped by me, but in general if you need to
> create an MFD then it should be located in the MFD subsystem.
Thanks Lee, how about
1. Move the i2c client probe, misc device registration and rmi_mailbox_xfer() function from existing hwmon/sbrmi.c to a drivers/mfd (Instead of drivers/misc)
a. Provide an ioctl interface through misc device node /dev/sbrmiX for the user space to invoke the following protocols.
- Mailbox xfer (already defined in sbrmi_mailbox_xfer())
- CPUID access
- MCAMSR access
2. Add an MFD device with a cell, which probes the hwmon/sbrmi and continues to report power using the symbols exported by the mfd/sbrmi.
>
>> drivers/mailbox/ supports mailbox style communication. I don't know if that
>> would apply to the mailbox functionality implemented here.
I've explored that path, and APML mailbox does not fit well into the
design, we do not have a dedicated interrupt line as well.
> --
> Lee Jones [李琼斯]
regards,
Naveenk
>
next prev parent reply other threads:[~2024-05-15 11:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 22:05 [PATCH 1/2] sbrmi: Use regmap subsystem Naveen Krishna Chatradhi
2024-05-02 22:05 ` [PATCH 2/2] sbrmi: Add support for APML protocols Naveen Krishna Chatradhi
2024-05-02 22:26 ` Guenter Roeck
2024-05-14 19:15 ` Chatradhi, Naveen Krishna
2024-05-14 19:47 ` Guenter Roeck
2024-05-15 10:32 ` Lee Jones
2024-05-15 11:30 ` Chatradhi, Naveen Krishna [this message]
2024-05-02 22:44 ` [PATCH 1/2] sbrmi: Use regmap subsystem Guenter Roeck
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=269884a8-da86-4cb5-b4eb-2827578608d4@amd.com \
--to=naveenkrishna.chatradhi@amd.com \
--cc=Akshay.Gupta@amd.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=lee@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=nchatrad@amd.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).