From: "Gupta, Akshay" <Akshay.Gupta@amd.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
linux@roeck-us.net, arnd@arndb.de,
naveenkrishna.chatradhi@amd.com
Subject: Re: [PATCH 3/6] misc: sbrmi: Use regmap subsystem
Date: Thu, 4 Jul 2024 19:56:34 +0530 [thread overview]
Message-ID: <1be9ef16-46f9-1312-2a61-4d0038e2d32f@amd.com> (raw)
In-Reply-To: <2024070400-sweat-playback-3a80@gregkh>
On 7/4/2024 5:23 PM, Greg KH wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Thu, Jul 04, 2024 at 11:16:21AM +0000, Akshay Gupta wrote:
>> - regmap subsystem provides multiple benefits over direct smbus APIs
> In what way, please document.
Answered below.
>
>> - The susbsytem can be helpful in following cases
>> - Differnet types of bus (i2c/i3c)
>> - Different Register address size (1byte/2byte)
> Is that what is happening here? I don't see i3c support...
This is a preparation for
1. I3C support: planning to add support, on AMD platforms BMC can
communicate with SBRMI over I2C/I3C
2. patch 6/6 in patch series, is adding support for 2 bytes SBRMI
register address size
>> --- a/include/misc/amd-sb.h
>> +++ b/include/misc/amd-sb.h
>> @@ -7,8 +7,8 @@
>> #define _AMD_SB_H_
>>
>> #include <linux/mutex.h>
>> -#include <linux/i2c.h>
> Why remove this?
In this patch "struct i2c_client" is removed, so no need for the header
inclusion.
>
>> #include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> /*
>> * SB-RMI supports soft mailbox service request to MP1 (power management
>> * firmware) through SBRMI inbound/outbound message registers.
>> @@ -23,11 +23,11 @@ enum sbrmi_msg_id {
>>
>> /* Each client has this additional data */
>> struct sbrmi_data {
>> - struct i2c_client *client;
>> + struct regmap *regmap;
>> struct mutex lock;
>> struct platform_device *pdev;
>> u32 pwr_limit_max;
>> -};
>> +} __packed;
> Why is this suddenly required to be __packed?
>
> Isn't that going to cause more problems than it is worth? And why is it
> worth it at all?
I will look into this and update.
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2024-07-04 14:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 11:16 [PATCH 0/6] misc: add amd side-band functionality Akshay Gupta
2024-07-04 11:16 ` [PATCH 1/6] hwmon/misc sbrmi: Move core sbrmi from hwmon to misc Akshay Gupta
2024-07-04 11:47 ` Greg KH
2024-07-04 13:57 ` Gupta, Akshay
2024-07-04 11:16 ` [PATCH 2/6] misc: sbrmi: Add platform device add to create platform device Akshay Gupta
2024-07-04 11:50 ` Greg KH
2024-07-04 14:13 ` Gupta, Akshay
2024-07-04 11:16 ` [PATCH 3/6] misc: sbrmi: Use regmap subsystem Akshay Gupta
2024-07-04 11:53 ` Greg KH
2024-07-04 14:26 ` Gupta, Akshay [this message]
2024-07-04 11:16 ` [PATCH 4/6] misc: sbrmi: Clear sbrmi status register bit SwAlertSts Akshay Gupta
2024-07-04 11:16 ` [PATCH 5/6] misc/hwmon: sbrmi: Add support for APML protocols Akshay Gupta
2024-07-04 11:16 ` [PATCH 6/6] misc: sbrmi: Add support for new revision Akshay Gupta
2024-07-04 11:54 ` Greg KH
2024-07-04 14:28 ` Gupta, Akshay
2024-07-04 11:48 ` [PATCH 0/6] misc: add amd side-band functionality Greg KH
2024-07-04 14:47 ` Gupta, Akshay
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=1be9ef16-46f9-1312-2a61-4d0038e2d32f@amd.com \
--to=akshay.gupta@amd.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=naveenkrishna.chatradhi@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