07:43 <krzk> Grimler: the short answer is - driver is in poor shape, not properly maintained. Long answer: driver was designed/developed to work with platform data.

07:44 <krzk> Grimler: it receives essential ModelGauge m3 configuration via platform data and configures itself to provide the best State of Charge via SOCAV/REPSOC registers.

07:45 <krzk> Grimler: However over time driver was used also on DT platforms which do not provide that configuration... or rather - providing ModelGauge m3 configuration was not added to DT-based platforms.

07:45 <krzk> Grimler: On ACPI platforms, the platform data with ModelGauge m3 might still be provided - I don't know, this might work.

07:47 <krzk> Grimler: anyway, on DT based platforms the ModelGauge is left unconfigured or default (to what was written in factory, assuming Samsung flashes internal chip permanently?) and driver still uses all registers as if ModelGauge was programmed.

07:48 <krzk> Grimler: this is wrong. For a case without configuration (!pdata->config_data), driver should revert back to simple mode (ModelGauge m1, I think), so use SOCAV and other registers which do not rely on ModelGauge m3.

07:49 <krzk> Grimler: The driver should be tested with few different batteries - if every timer the Capacity is bogus, it's a proof that driver cannot work without ModelGauge m3 and should switch to simple SOCAV. Entire driver should be rewritten to have this in mind.

07:51 <krzk> Grimler: Other register which output depends on ModelGauge m3 is OCV (0xEE). This one should also be ignored and not reported to the user (because it will confuse him).

07:52 <krzk> On the other hand, driver does not use OCV (0xEE) but OCVInternal which looks like present only in some devices.