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: <61a54367-2406-4106-bf8b-9fda4f2d11a6@uclouvain.be>
Date: Tue, 3 Dec 2024 11:30:38 +0100
From: Thomas Antoine <t.antoine@...ouvain.be>
To: André Draszik <andre.draszik@...aro.org>,
 Sebastian Reichel <sre@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Dimitri Fedrau <dima.fedrau@...il.com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Peter Griffin <peter.griffin@...aro.org>,
 Alim Akhtar <alim.akhtar@...sung.com>
Cc: 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 10:45, André Draszik wrote:
> On Tue, 2024-12-03 at 07:23 +0000, André Draszik wrote:
>> On Tue, 2024-12-03 at 06:47 +0000, André Draszik wrote:
>>> Hi Thomas,
>>>
>>> Thanks for looking into this!
>>>
>>>> From: Thomas Antoine <t.antoine@...ouvain.be>
>>>>
>>>> The Maxim max77759 fuel gauge has the same interface as the Maxim max1720x
>>>> except for the non-volatile memory slave address which is not available.
>>>
>>> It is not fully compatible, and it also has a lot more registers.
>>>
>>> For example, the voltage now is not in register 0xda as this driver assumes.
>>> With these changes, POWER_SUPPLY_PROP_VOLTAGE_NOW just reads as 0. 0xda
>>> doesn't exist in max77759
>>>
>>> I haven't compared in depth yet, though.
>>
>> Regarding the regmap in this driver, please see below comparison I had
>> collected some time ago:
>>
>> 	regmap_reg_range(0x24, 0x26), // exists
>> 	regmap_reg_range(0x30, 0x31), // exists
>> 	regmap_reg_range(0x33, 0x34), // exists
>> 	regmap_reg_range(0x37, 0x37), // exists
>> 	regmap_reg_range(0x3B, 0x3C), // exists
>> 	regmap_reg_range(0x40, 0x41), // exists
>> 	regmap_reg_range(0x43, 0x44), // exists
>> 	regmap_reg_range(0x47, 0x49), // exists
>> 	regmap_reg_range(0x4B, 0x4C), // exists
>> 	regmap_reg_range(0x4E, 0xAF), // 0x4e 0x4f exists
>> 	regmap_reg_range(0xB1, 0xB3), // exists
>> 	regmap_reg_range(0xB5, 0xB7), // exists
>> 	regmap_reg_range(0xBF, 0xD0), // 0xd0 exists
>> 	0xd1 .. 0xdb don't exist
>> 	regmap_reg_range(0xDB, 0xDB),
>> 	regmap_reg_range(0xE0, 0xFF), // 0xfb 0xff exist
>>
>> the comments refer to whether or not the register exists in max77759
> 
> I think this should make it more clear:
> allow:
> 	regmap_reg_range(0x00, 0xff),
> deny:
> 	regmap_reg_range(0x50, 0xaf),
> 	regmap_reg_range(0xc0, 0xcf),
> 	regmap_reg_range(0xd1, 0xdb),
> 	regmap_reg_range(0xe0, 0xfa),
> 	regmap_reg_range(0xfc, 0xfe),

Should I explicitly deny their use in the code for the max77759 or is it
just for information?

Best regards,
Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ