Re: [PATCH v3 0/2] Add support for Battery Status AMS

[Amit Sunil Dhamne <amitsd@google.com>]

Hi Sebastian,

On 6/8/26 12:20 PM, Amit Sunil Dhamne wrote:
> Hi Sebastian,
>
> On 6/4/26 10:36 AM, Sebastian Reichel wrote:
>> 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.
> Thanks for pointing that out. Which one would you prefer?:
>
> 1. Bake this into the power_supply_get_battery_all() implementation by
> either passing the scope as an argument or directly implementing the
> filtering on POWER_SUPPLY_SCOPE_SYSTEM without the argument.
>
> 2. power_supply_get_battery_all() returns all battery type power
> supplies but tcpm filters them. Note that tcpm still keeps all
> references to all batteries because of the review comments in [2].
>
>
> [2]
> https://lore.kernel.org/all/4e4a63a4-9d07-4b77-a8dc-ba19c9a803f7@kernel.org/
>
>> 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?
> Just to clarify, I meant fixed and not "always present". The spec
> defines fixed battery as:
>
> "A Battery that is not easily removed or replaced by an end user e.g.,
> requires a special tool to access or is soldered in."
>
> Theoretically, you could still have a phone with the fixed battery
> removed and the system powered by USB.
>
> So, while this is more relevant to hot-swappable battery case (, which
> is defined by the spec as: "A Battery that is easily accessible for a
> user to remove or change for another Battery.") it wouldn't be totally
> off the mark to add that check here.
>
> So while I lean on having the check present, I am okay either way.
>
>
>> Not sure if this is fixable, but you implicitly rely on the battery
>> driver to be probed before TCPM reaches this.
>
> Given the power supply architecture, the probe order is deterministic: a
> power supplier driver (e.g., the TCPC) must probe before the supplied
> devices (charger, fuel-gauge). Because of this, TCPM will naturally be
> up and running before the fuel gauge during early boot.
>
> Holding off TCPM interactions to wait for downstream devices to probe
> isn't a viable option. TCPM operates under strict USB-PD timing
> constraints. Stalling the state machine to wait for a fuel gauge could
> violate these timings and cause the PD contract to fail entirely.
> Furthermore, a fuel gauge is not required to establish a valid PD
> contract; Battery Status and Battery Cap messages are purely telemetry.
>
> The current approach handles this cleanly:
> (1) If a request comes in during early boot before the battery is
> available, we safely send an unsupported message.
> (2) The port partner will continue to retry for battery status/caps
> irrespective of the reply.
> (3) Once the system is fully booted and the fuel gauge has probed, the
> telemetry is reported correctly.
>
> We initially considered a DT-property based approach so TCPM would know
> the exact number of batteries (and their reference phandles) at probe
> time, but we moved away from that to avoid duplicating DT properties
> (based on feedback in [1]). The current implementation safely
> prioritizes critical power negotiation over optional telemetry while
> still fulfilling the PD requirements in the steady state.
>
>
> Thanks,
>
> Amit


I want to gently follow up on this discussion :) . Looking forward to 
hearing your feedback on the open threads above.


Thanks,

Amit

>
>
>> Greetings,
>>
>> -- Sebastian