linux-kernel - Re: [PATCH v3 2/4] hwmon: Add support for SPD5118 compliant temperature sensors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5d95d3d-1ca5-43f1-8c17-d24bd38f28b7@roeck-us.net>
Date: Fri, 31 May 2024 20:40:11 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
 linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org,
 Armin Wolf <W_Armin@....de>, Thomas Weißschuh
 <linux@...ssschuh.net>, René Rebe <rene@...ctcode.de>
Subject: Re: [PATCH v3 2/4] hwmon: Add support for SPD5118 compliant
 temperature sensors

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