From: Guenter Roeck <linux@roeck-us.net>
To: "Wolfram Sang" <wsa+renesas@sang-engineering.com>,
linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
linux-kernel@vger.kernel.org, "Armin Wolf" <W_Armin@gmx.de>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"René Rebe" <rene@exactcode.de>
Subject: Re: [PATCH v3 2/4] hwmon: Add support for SPD5118 compliant temperature sensors
Date: Fri, 31 May 2024 20:40:11 -0700 [thread overview]
Message-ID: <e5d95d3d-1ca5-43f1-8c17-d24bd38f28b7@roeck-us.net> (raw)
In-Reply-To: <uvikiflwuoz3szchmvke7p3ymqvcngkydehk6cctdv24cxsh6r@7d5vxcvdca6l>
On 5/31/24 18:28, Wolfram Sang wrote:
>
>> +/* Return 0 if detection is successful, -ENODEV otherwise */
>> +static int spd5118_detect(struct i2c_client *client, struct i2c_board_info *info)
>> +{
>> + struct i2c_adapter *adapter = client->adapter;
>> + int regval;
>> +
>> + if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
>> + I2C_FUNC_SMBUS_WORD_DATA))
>> + return -ENODEV;
>> +
>> + regval = i2c_smbus_read_word_swapped(client, SPD5118_REG_TYPE);
>> + if (regval != 0x5118)
>> + return -ENODEV;
>> +
>> + regval = i2c_smbus_read_word_data(client, SPD5118_REG_VENDOR);
>> + if (regval < 0 || !spd5118_vendor_valid(regval & 0xff, regval >> 8))
>> + return -ENODEV;
>> +
>> + regval = i2c_smbus_read_byte_data(client, SPD5118_REG_CAPABILITY);
>> + if (regval < 0)
>> + return -ENODEV;
>> + if (!(regval & SPD5118_CAP_TS_SUPPORT) || (regval & 0xfc))
>> + return -ENODEV;
>> +
>> + regval = i2c_smbus_read_byte_data(client, SPD5118_REG_TEMP_CLR);
>> + if (regval)
>> + return -ENODEV;
>> + regval = i2c_smbus_read_byte_data(client, SPD5118_REG_ERROR_CLR);
>> + if (regval)
>> + return -ENODEV;
>> +
>> + regval = i2c_smbus_read_byte_data(client, SPD5118_REG_REVISION);
>> + if (regval < 0 || (regval & 0xc1))
>> + return -ENODEV;
>> +
>> + regval = i2c_smbus_read_byte_data(client, SPD5118_REG_TEMP_CONFIG);
>> + if (regval < 0)
>> + return -ENODEV;
>> + if (regval & ~SPD5118_TS_DISABLE)
>> + return -ENODEV;
>> +
>> + strscpy(info->type, "spd5118", I2C_NAME_SIZE);
>> + return 0;
>> +}
>
> What about adding DDR5 to i2c_register_spd() and dropping this function?
>
Yes, that should be the next step. I didn't want to do that here because it
would introduce a cross-subsystem dependency. Of course, that depends a bit
on your position about such dependencies. If I do that as part of this series,
would you Ack it, or would you want to handle that through the i2c tree ?
Guenter
next prev parent reply other threads:[~2024-06-01 3:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 23:05 [PATCH v3 0/4] hwmon: Add support for SPD5118 compliant chips Guenter Roeck
2024-05-31 23:05 ` [PATCH v3 1/4] dt-bindings: trivial-devices: Add jedec,spd5118 Guenter Roeck
2024-06-01 15:19 ` Krzysztof Kozlowski
2024-05-31 23:05 ` [PATCH v3 2/4] hwmon: Add support for SPD5118 compliant temperature sensors Guenter Roeck
2024-06-01 1:28 ` Wolfram Sang
2024-06-01 3:40 ` Guenter Roeck [this message]
2024-06-02 20:18 ` Wolfram Sang
2024-06-02 21:24 ` Guenter Roeck
2024-06-01 19:14 ` Armin Wolf
2024-05-31 23:05 ` [PATCH RFT v3 3/4] hwmon: (spd5118) Add suspend/resume support Guenter Roeck
2024-06-01 19:17 ` Armin Wolf
2024-06-03 12:31 ` Stephen Horvath
2024-06-03 13:50 ` Guenter Roeck
2024-05-31 23:05 ` [PATCH RFT v3 4/4] hwmon: (spd5118) Add support for reading SPD data Guenter Roeck
2024-06-01 5:42 ` Guenter Roeck
2024-06-01 10:41 ` Thomas Weißschuh
2024-06-01 13:48 ` Guenter Roeck
2024-06-01 14:08 ` Thomas Weißschuh
2024-06-01 19:23 ` Armin Wolf
2024-06-02 7:55 ` Thomas Weißschuh
2024-06-02 15:25 ` Guenter Roeck
2024-06-02 16:06 ` Guenter Roeck
2024-06-01 1:26 ` [PATCH v3 0/4] hwmon: Add support for SPD5118 compliant chips Wolfram Sang
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=e5d95d3d-1ca5-43f1-8c17-d24bd38f28b7@roeck-us.net \
--to=linux@roeck-us.net \
--cc=W_Armin@gmx.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=rene@exactcode.de \
--cc=robh@kernel.org \
--cc=wsa+renesas@sang-engineering.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 NNTP newsgroup(s).