Fuel Gauge Device Driver API - Updated #44847
Description
name: RFC / Proposal
about: Submit an RFC / Proposal
title: 'Dedicated Battery Fuel Gauge Device Driver API'
labels: RFC
assignees: 'aaronemassey'
Introduction
Add a kernel device driver API for battery fuel gauge control.
Problem description
A limited battery fuel gauge API exists in the increasingly large sensor_channel
enum defined by the sensor API. However, fuel_gauges are also written to by
drivers (e.g. SMBus writes); this falls outside the purview of the sensor API.
Correction to above:
The writing to drivers is absolutely within the purview of the sensor API. I'm not entirely sure why that text made it in here. It is the case that no fuel gauge ICs make use of the sensor API's writing, but that doesn't preclude such behavior to exist.
Thank you to @trentp-igor for catching this error in the RFC.
The sensor API presuppose device drivers to do their own caching. Fuel gauges on
severely memory strained systems should allow application code to decide what's
important to cache (except for internal values that are necessary for the
driver's operation).
Proposed change
Add a battery fuel gauge device driver API that provides reading and fuel gauge
writing to (such as via smart battery SMBus) as a single device driver API.
Eventually deprecating the sensor API battery fuel gauge APIs in favor of the
dedicated battery driver API.
Detailed RFC
Proposed change (Detailed)
See the accompanying initial pull request for an initial MVP.
Followup changes will include a more full fledged SBS Gauge driver enabling
SMBus and other writes via the API extended in future PRs.
Dependencies
In future PRs, clients of the battery fuel gauge channels in the sensor API
will be migrated to leverage the new battery fuel gauge API. Eventually, the
battery fuel gauge APIs implemented in the sensor API will be deprecated and
removed.
Part of a Future/TBD Power Supply Subsystem Zephyr Ecosystem
In the initial pull request there were many comments indicating significant
interest in the creation of an overarching power supply subsystem, likely
drawing inspiration from the Linux Kernel's power supply
subsystem. This would
encompass working with fuel gauges and charger ICs from application code.
The creation of a fully fledged power supply subsystem is outside the scope of
this specific RFC. This RFC is specific to battery fuel gauges. However, these
comments were taken heavily into consideration and principally informed a
redesign of the initial fuel gauge API to better fit as a module under such a
future ecosystem. It's now intended to able to fit within the scope of a future
power subsystem roughly described by the below diagram.
The exact details of ownership, RFCs, and future PRs of the future APIs
described by this diagram are outside the scope of this RFC and should be
largely discussed out in a separate RFC/issue.
Concerns and Unresolved Questions
Minimum Viable Product (MVP)
The initial pull request is intended to be an MVP. Notably, this PR does not
include any way to expose writing to fuel-gauge registers, such as SBS extended
registers. This will be designed and iterated upon in follow-up PRs.
Not an Expert
I am no expert on batteries nor Zephyr, so there may be cases I do not know to consider.
Alternatives
Status Quo
Pros
- No additional work on deprecating and migrating existing code
Cons
- No unified mature API for battery fuel gauge reading/writing
- Clients of the current fuel gauge API are potentially forced to pay for cached
fuel gauge parameters.
Keep Both
Instead of replacing the fuel gauge channels in the sensor API, just add the
new battery fuel gauge device driver API.
Pros
- No deprecation work is necessary.
Cons
- Maintaining two similar APIs for the similar or same use-case could result in
inconsistencies that could frustrate clients. - Also maintaining two separate sets of drivers is problematic (e.g. they fall
out of sync).
Metadata
Metadata
Assignees
Type
Projects
Status