14:16 <Grimler> Hi, two weeks ago interrupt storm on max17042 was discussed. In max17042_set_soc_threshold we are reading RepSOC (filtered soc), and then setting the thresholds to +/- 1 %-point of that. I was under the impression that the thresholds are used to detect when the soc goes below (or above) some value, to detect when battery reaches low (or high) values, but given the current max17042 code maybe I have

14:16 <Grimler> misunderstood it? Is it just suppose to trigger (once) to indicate that the soc has reached a new percentage?

14:16 <Grimler> In max17040 similar functionality is implemented, but there the (lower) threshold can be set to a value between 1 and 32 % with the property alert-low-soc-level in the device tree.

14:43 <krzk> Grimler: The tresholds are around current SoC, so when SoC changes, alert interrupt is triggered. Since the SoC is wrong, alarm interrupt is triggered immediately and we set new tresholds which match again wrong SoC.

14:44 <krzk> Grimler: thus the alarm interrupt will be hit again... and we repeat to set tresholds... to hit alarm again.

14:44 <krzk> Grimler: that was my hipothessis. Someone with a device should verify it. :)

14:45 <krzk> Grimler: max17040 is a completely different type of a device, different driver. I don't get the comparison here or how is it related to this problem.

15:03 <Grimler> krzk: Alright, thanks, maybe related to the other issue where we seem to use MAX17042_VFSOC instead of MAX17042_RepSOC to get soc then? RepSOC is used to set the thresholds as well. I'll investigate further

15:03 <Grimler> > max17040 is a completely different type of a device, different driver. I don't get the comparison here or how is it related to this problem.

15:03 <Grimler> I assumed they were somewhat similar based on the name, and tried to compare the soc alert functions, my bad

15:04 <Grimler> .. other issue where we seem to need to use MAX17042_VFSOC instead of MAX17042_RepSOC to get soc then?*