devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).