PD 3.1 v1.8 Spec necessitates a response to Get_Battery_Status request
from the port partner (see "6.13.2 Applicability of Data Message").
This patchset adds support to get all the battery type power supplies
and query them to report the telemetry required to build a Battery
Status Message. Right now, this submission assumes all the battery type
power supplies that exist in the system are fixed (meaning cannot be hot
swapped).

Previously, I had sent a patch series [1]. However there were some
concerns. Broadly:
  * No client drivers
  * Duplicating dt properties
To address the above issues, we now have Fuel Gauge and Charger drivers.
Also, I have rectified my approach to fetch information about batteries
from the power supply core.

While, the original patch series [1] added support for Battery Caps as
well, this patch series only adds support for Battery Status. Therefore,
I am sending it as a new series while incorporating relevant feedback.

[1] https://lore.kernel.org/all/20250507-batt_ops-v2-0-8d06130bffe6@google.com/

Patches in series:
[A] "power: supply: Add helpers to get and put arrays of power supply handles"
[B] "usb: typec: tcpm: Add support for Battery Status response message"

Technical dependency of patches:
[B] depends on [A] due to usage of `power_supply_get_battery_all` &
`power_supply_put_battery_all` APIs.

Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
---
Changes in v3:
- Suggested by Hans:
  - s/power_supply_put_array/power_supply_put_battery_all.
  - Call kfree in power_supply_put_battery_all().
  - Change the datatype for fixed_batt from an array of pointers to a
    double pointer.
  - Directly store the power supply pointers returned by
    power_supply_get_battery_all() into fixed_batt.
  - As we are directly storing all battery type power supplies returned
    by *_get_battery_all() but as per the USB PD specification, tcpm
    only supports reporting of up to 4 fixed batteries, we add
    additional checks to satisfy the latter condition.
  - It was suggested that fixed_batt_cnt be changed to int to store the
    return value of *_get_battery_all(). However, I am leaving it as is
    because: in case the retval is < 0, we don't care for the error
    value beyond the scope of the function it's called in. It's sufficient
    to just have fixed_batt_cnt to stay 0. Lmk if you still want it to
    be int and I will change it.

- Suggested by Badhri (internal review)
  - It's not necessary from a PD protocol perspective that a Sink Cap
    Extended AMS should always precede the Battery Status AMS.
    Therefore, we should also get battery references during Battery
    Status AMS in case fixed_batteries was unintialized.
- Link to v2: https://lore.kernel.org/r/20260527-batt-status-v2-0-4282985165f3@google.com

Changes in v2:
- Suggested by Hans De Goede:
  - Added helper power_supply_put_array() to release array of psy refs.
  - Modified tcpm implementation to use the above.
  - Drop "power: supply: max17042: add handler for energy_now property"
    commit.
  - Offload energy_now calculation to tcpm.
- Minor changes to description comments of
  power_supply_get_battery_all() to improve brevity.
- Link to v1: https://lore.kernel.org/r/20260515-batt-status-v1-0-fed6b7d8cea7@google.com

---
Amit Sunil Dhamne (2):
      power: supply: Add helpers to get and put arrays of power supply handles
      usb: typec: tcpm: Add support for Battery Status response message

 drivers/power/supply/power_supply_core.c | 133 ++++++++++++++++++++++++++++++
 drivers/usb/typec/tcpm/tcpm.c            | 135 ++++++++++++++++++++++++++++++-
 include/linux/power_supply.h             |  15 ++++
 include/linux/usb/pd.h                   |  29 +++++++
 4 files changed, 309 insertions(+), 3 deletions(-)
---
base-commit: 57b8e2d666a31fa201432d58f5fe3469a0dd83ba
change-id: 20260501-batt-status-16b6761c0bb1

Best regards,
-- 
Amit Sunil Dhamne <amitsd@google.com>

Hi,

On Tue, Jun 02, 2026 at 10:47:05PM +0000, Amit Sunil Dhamne via B4 Relay wrote:
> PD 3.1 v1.8 Spec necessitates a response to Get_Battery_Status request
> from the port partner (see "6.13.2 Applicability of Data Message").
> This patchset adds support to get all the battery type power supplies
> and query them to report the telemetry required to build a Battery
> Status Message. Right now, this submission assumes all the battery type
> power supplies that exist in the system are fixed (meaning cannot be hot
> swapped).
> 
> Previously, I had sent a patch series [1]. However there were some
> concerns. Broadly:
>   * No client drivers
>   * Duplicating dt properties
> To address the above issues, we now have Fuel Gauge and Charger drivers.
> Also, I have rectified my approach to fetch information about batteries
> from the power supply core.
> 
> While, the original patch series [1] added support for Battery Caps as
> well, this patch series only adds support for Battery Status. Therefore,
> I am sending it as a new series while incorporating relevant feedback.
> 
> [1] https://lore.kernel.org/all/20250507-batt_ops-v2-0-8d06130bffe6@google.com/
> 
> Patches in series:
> [A] "power: supply: Add helpers to get and put arrays of power supply handles"
> [B] "usb: typec: tcpm: Add support for Battery Status response message"
> 
> Technical dependency of patches:
> [B] depends on [A] due to usage of `power_supply_get_battery_all` &
> `power_supply_put_battery_all` APIs.
> 
> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
> ---

I think you want to filter on batteries that are
POWER_SUPPLY_SCOPE_SYSTEM? Otherwise this would also give you
battery devices for something like a cordless mouse.

You mention that this is assuming batteries to be always present,
but handle POWER_SUPPLY_PROP_PRESENT. So basically a battery, which
has POWER_SUPPLY_PROP_PRESENT=0 would violate the PD spec as Fixed
Batteries are not supposed to have this unset?

Not sure if this is fixable, but you implicitly rely on the battery
driver to be probed before TCPM reaches this.

Greetings,

-- Sebastian