This code hasn't changed in many years, but my recollection is:

1. The full_factor pref and behavior exists because a bunch of devices have batteries that charge much more slowly as they approach a full charge or stop charging altogether before reaching a full charge. We report charges above this threshold as full since otherwise it's impossible for the user to know when to stop charging.

2. We don't use the same behavior when line power isn't connected since it'd be weird if a device continued to report that its battery was full after running on battery power for an extended period of time and then suddenly started dropping at a constant rate.

I agree that the discrepancy is weird, but the obvious alternatives seem at least as weird. I'm not excited about switching to a complicated approach that yields less-deterministic behavior, either.

on 1. Dai noted crrev.com/c/169549 in his investigation of b/109954565 issue as well.  

I think the CL was introduced before the time of power_supply_full_factor and ultimately should be removed.

There is a third value that also plays into this: 

In EC, ec/include/battery.h
L35: #define BATTERY_LEVEL_NEAR_FULL		 97

This controls the LED indicating fully charged. 

Adding two screenshots of my observations

First screenshot is in the order of ec battery percentage first going up then going down, second is the same measurement but split by whether AC is plugged. 

The discrepancy between battery.als level (94% as full when AC plugged) and EC BATTERY_LEVEL_NEAR_FULL (97% when LED indicate full charge) is confusing to users. 

Deleted: Screenshot from 2018-10-26 12-18-13.png 210 KB

	Screenshot from 2018-10-26 12-18-13.png 210 KB View Download

Deleted: Screenshot from 2018-10-26 12-18-40.png 182 KB

	Screenshot from 2018-10-26 12-18-40.png 182 KB View Download

Here is a test CL: when AC is plugged, "power_supply_info" percentage jumps to 100 at 98.5, instead of 94.

https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/1303453

This is the CL where battery.asl is originally uploaded:
https://review.coreboot.org/c/coreboot/+/2481

This CL already has the part to set the "battery percentage" jumping point:
https://review.coreboot.org/c/coreboot/+/2481/2/src/ec/google/chromeec/acpi/battery.asl#205

Here is another test CL:

https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/1310974

When AC connected, percentage goes up to 99.0035 and stays there for a very long time. After leaving device charging for a long time, battery
reaches 100, and battery stopped allowing charging, which is expected behavior. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/0a641f1f03af57818b62d96e9b85648cbc0c14e2

commit 0a641f1f03af57818b62d96e9b85648cbc0c14e2
Author: Daisuke Nojiri <dnojiri@chromium.org>
Date: Thu Nov 08 08:48:03 2018

UPSTREAM: chromeec: Disable battery remaining capacity workaround

If remaining charge is more than x% of the full capacity, the
remaining charge is raised to the full capacity before it's
reported to the rest of the system.

Some batteries don't update full capacity timely or don't update it
at all. On such systems, compensation is required to guarantee
the remaining charge will be equal to the full capacity eventually.

On some systems, Rohm charger generates audio noise when the battery
is fully charged and AC is plugged. A workaround is to do charge-
discharge cycles between 93 and 100%. On such systems, compensation
was also applied to mask this cycle from users.

This used to be done in ACPI, thus, all software components except EC
was able to see the compensated charge. This patch is part of the
effort of moving the logic to EC. With this and the EC changes, EC
can see what the rest of the system sees, thus, can control LEDs
synchronously (to the display percentage).

Another rationale of this move is EC can perform more granular and
precise compensation than ACPI since it has more knowledge about the
battery and the charger.

CQ-DEPEND=CL:1312204
BUG=b:109954565,b:80270446, chromium:899120 
BRANCH=none
TEST=Verify charge LED changes to white (full) on Sona synchronously
to the display percentage.
TEST=Verify charge LED changes to blinking white (low) on Sona
within 30 seconds synchronously to the display percentage.

Change-Id: I6718ec3fd2853f61d82b7c3921328e157cf31688
Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Commit-Id: 55a972236ee93d36bd3df4e8e5680ba447242bd7
Original-Change-Id: I0b51911b90dc2e7fcf5c730c54d9fda1fea76aa9
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/29441
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1320195
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>

[modify] https://crrev.com/0a641f1f03af57818b62d96e9b85648cbc0c14e2/src/ec/google/chromeec/acpi/battery.asl

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/297d51d8a3664bc362ac7f5ae75ab4692ee43518

commit 297d51d8a3664bc362ac7f5ae75ab4692ee43518
Author: Daisuke Nojiri <dnojiri@chromium.org>
Date: Thu Nov 08 19:33:39 2018

UPSTREAM: chromeec: Disable battery remaining capacity workaround

If remaining charge is more than x% of the full capacity, the
remaining charge is raised to the full capacity before it's
reported to the rest of the system.

Some batteries don't update full capacity timely or don't update it
at all. On such systems, compensation is required to guarantee
the remaining charge will be equal to the full capacity eventually.

On some systems, Rohm charger generates audio noise when the battery
is fully charged and AC is plugged. A workaround is to do charge-
discharge cycles between 93 and 100%. On such systems, compensation
was also applied to mask this cycle from users.

This used to be done in ACPI, thus, all software components except EC
was able to see the compensated charge. This patch is part of the
effort of moving the logic to EC. With this and the EC changes, EC
can see what the rest of the system sees, thus, can control LEDs
synchronously (to the display percentage).

Another rationale of this move is EC can perform more granular and
precise compensation than ACPI since it has more knowledge about the
battery and the charger.

CQ-DEPEND=CL:1312204
BUG=b:109954565,b:80270446, chromium:899120 
BRANCH=none
TEST=Verify charge LED changes to white (full) on Sona synchronously
to the display percentage.
TEST=Verify charge LED changes to blinking white (low) on Sona
within 30 seconds synchronously to the display percentage.

Change-Id: I6718ec3fd2853f61d82b7c3921328e157cf31688
Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Commit-Id: 55a972236ee93d36bd3df4e8e5680ba447242bd7
Original-Change-Id: I0b51911b90dc2e7fcf5c730c54d9fda1fea76aa9
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/29441
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1320195
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 0a641f1f03af57818b62d96e9b85648cbc0c14e2)
Reviewed-on: https://chromium-review.googlesource.com/c/1327384
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>

[modify] https://crrev.com/297d51d8a3664bc362ac7f5ae75ab4692ee43518/src/ec/google/chromeec/acpi/battery.asl

See b:109954565 for details.