Re: [PATCH 2/4] dt-bindings: power: supply: add max77759-fg flavor and don't require nvme address

["André Draszik" <andre.draszik@linaro.org>]

On Wed, 2024-12-04 at 14:13 +0100, Thomas Antoine wrote:
> On 12/3/24 11:40, André Draszik wrote:
> > On Tue, 2024-12-03 at 11:23 +0100, Thomas Antoine wrote:
> > > On 12/3/24 08:12, André Draszik wrote:
> > > > On Mon, 2024-12-02 at 14:07 +0100, Thomas Antoine via B4 Relay wrote:
> > > > > From: Thomas Antoine <t.antoine@uclouvain.be>
> > > > > 
> > > > > As the Maxim max77759 fuel gauge has no non-volatile memory slave address,
> > > > > make it non-obligatory. Except for this, the max77759 seems to behave the
> > > > > same as the max1720x.
> > > > 
> > > > What about the battery characterization tables? Aren't they needed for
> > > > correct reporting?

[...]

> > 
> I looked into it. The probe function launches a delay work
> max1720x_model_work which will try multiple times to run
> max1720x_model_load which leads to
> max_m5_load_gauge_model -> max_m5_update_custom_model
> 
> This last function writes 0x0059 to 0x62 and 0x00c4 to 0x63 which unlocks
> the addresses from 0x80 to 0xaf.

OK. The regmap I had proposed was excluding those based on the
datasheet I have, but you probably noticed.

[...]

> If it is indeed the case and that all of those are equivalent to their
> max1720x counterpart, I think the management of those values should be
> added in another patch which implements it for both the max1720x (and possibly the
> max77759) as the mainline driver does not do anything with those values
> currently.

Thanks for the analysis! And yes, I agree.

Adding new required properties to a DT binding is an ABI break,
therefore I was trying to ensure the binding is complete from
the start.

Cheers,
Andre'