linux-kernel - Re: [PATCH v6 2/2] dt-bindings: 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] [day] [month] [year] [list]

Message-ID: <dfde0a91359b87d4eff88815b4112ad17cca9935.camel@linaro.org>
Date: Fri, 19 Sep 2025 14:17:26 +0100
From: André Draszik <andre.draszik@...aro.org>
To: Sebastian Reichel <sebastian.reichel@...labora.com>
Cc: Thomas Antoine <t.antoine@...ouvain.be>, Conor Dooley
 <conor@...nel.org>,  Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,  Peter Griffin
 <peter.griffin@...aro.org>, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org, 	devicetree@...r.kernel.org
Subject: Re: [PATCH v6 2/2] dt-bindings: power: supply: add support for
 MAX77759 fuel gauge

Hi,

On Fri, 2025-09-19 at 00:32 +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Thu, Sep 18, 2025 at 02:02:55PM +0100, André Draszik wrote:
> > 
> > Additionally, the FG block can also measure temperature and battery ID. For
> > those, a combination of (top-level) PMIC and FG registers are needed
> > unfortunately. Which means that the FG should probably be an MFD child
> > device, even though the FG itself doesn't depend on the top-level. Otherwise
> > it'd be hard to access the top-level PMIC register.
> 
> My understanding is, that the FG has a dedicated I2C device address

Yes, that is correct. It also has its own dedicated interrupt output.

> and thus cannot be a simple MFD child of the PMIC.

The core can still create child devices if a child uses a different
i2c address, as already done by the max77759 core driver for the charger
(which e.g. doesn't have its own interrupt). Some MFD other core drivers
also use such an approach.


[...]

> Assuming I understood things correctly, I think I suggest to model
> things like this for the battery temperature/ID:

Nice, yes, that should work - didn't think of that...

Cheers,
Andre'