linux-kernel - Re: [PATCH 1/4] power: supply: add support for max77759 fuel gauge

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <9426d88b-0a8b-4cd1-81a4-83cfa61bb595@uclouvain.be>
Date: Tue, 3 Dec 2024 10:25:13 +0100
From: Thomas Antoine <t.antoine@...ouvain.be>
To: Dimitri Fedrau <dima.fedrau@...il.com>
Cc: Sebastian Reichel <sre@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, Peter Griffin <peter.griffin@...aro.org>,
 Alim Akhtar <alim.akhtar@...sung.com>, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH 1/4] power: supply: add support for max77759 fuel gauge

On 12/3/24 08:35, Dimitri Fedrau wrote:
> Hi Antoine,
> 
> Am Mon, Dec 02, 2024 at 02:07:15PM +0100 schrieb Thomas Antoine via B4 Relay:
>> From: Thomas Antoine <t.antoine@...ouvain.be>
>> +#include <linux/types.h>
>>  
> No need to include it, it is done by <linux/i2.c> which includes
> <linux/device.h> which includes <linux/types.h>

Hi,
Will remove for v2.

>>  static const char *const max17201_model = "MAX17201";
>>  static const char *const max17205_model = "MAX17205";
>> +static const char *const max77759_model = "MAX77759";
>>  
>>  struct max1720x_device_info {
>>  	struct regmap *regmap;
>> @@ -54,6 +57,21 @@ struct max1720x_device_info {
>>  	int rsense;
>>  };
>>  
>> +struct chip_data {
>> +	u16 default_nrsense; /* in regs in 10^-5 */
>> +	u8 has_nvmem;
>> +};
>> +
>> +static const struct chip_data max1720x_data  = {
>> +	.default_nrsense = 1000,
>> +	.has_nvmem = 1,
>> +};
>> +
>> +static const struct chip_data max77759_data = {
>> +	.default_nrsense = 500,
>> +	.has_nvmem = 0,
>> +};
>> +
> You can get rid of chip_data by reading rsense from DT and moving
> has_nvmem to max1720x_device_info. By doing so you don't have to rely on
> default values. Either it is specified by DT or by rsense value in
> nvmem.

I guess I can just get has_nvmem by seeing if of_property_read of the
rsense value fails. As long as the binding is well defined as to not
allow a rsense value for the max1720x, there should be no problem.
Will do that for v2.

Thanks, best regards,
Thomas