It would definitely be very helpful to make the intent and naming clear.

It seems like it would be beneficial to have a single enum that accounted for all connection states of a battery. It is confusing going to different functions for different pieces of state. Also having multiple functions forces callers to know which function to call in all situations (making it easy to miss a condition).

If we had a get_battery_connection_state() method that accounted for all connection states, I can see it having the following states:

PHYSICALLY_ABSENT
PHYSICALLY_PRESENT_ERROR (can't communicate with battery)
PHYSICALLY_PRESENT_UNIT (haven't tried communication yet)
PHYSICALLY_PRESENT_CUTOFF (disconnected - needs trickle current to wake up)
PHYSICALLY_PRESENT_CUTOFF_PENDING (disconnect is scheduled after next reboot)
PHYSICALLY_PRESENT_CONNECTED (providing power - still may need to check for minimum charge % for SoC)

(We will tweak names in final enum)

Cutoff is the same thing as disconnected, right?
Are there any other connection states we need to account for?

I was thinking about adding PHYSICALLY_PRESENT_CONNECTED_NOT_ENOUGH_POWER (used when CONFIG_CHARGER_MIN_BAT_PCT_FOR_POWER_ON is defined), but I don't think it belongs in this concept. I think it makes more sense to check for PHYSICAL_PRESENT_CONNECTED then for percentage separately.

I'd also like to nominate battery_is_cut_off() for renaming, since it tells you whether the battery is scheduled to be cut off at next shutdown, not whether the battery is currently cut off.

See: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1072637/5/common/battery_fuel_gauge.c#214

This bug has an owner, thus, it's been triaged. Changing status to "assigned".