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@xxxxxxxxxxxx> > > > > > > > > > > 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'
