Re: [PATCH 1/2] dt-bindings: soc: qcom: pmic-glink: Document batteryless property

[Konrad Dybcio]

On 5/21/26 9:20 AM, Krzysztof Kozlowski wrote:
> On 21/05/2026 09:13, Kamal Wadhwa wrote:
>> On Tue, May 19, 2026 at 12:35:13PM +0200, Krzysztof Kozlowski wrote:
>>> On Tue, May 19, 2026 at 01:55:26PM +0530, Rakesh Kota wrote:
>>>>
>>>>> And isn't lack of monitored battery property enough to indicate that?
>>>>
>>>> Regarding monitored-battery — its absence alone isn't sufficient. The
>>>> BATT_ID line on debug boards is pulled to ~10kΩ, which is used during
>>>> development phase where some battery properties are still present. The
>>>> same ~10kΩ value is also used on some genuinely battery-less production
>>>> platforms where no battery properties exist, making auto-detection
>>>> unreliable. Hence the need for an explicit DT property to identify
>>>> hardware platforms where no battery populated. 
>>>
>>> I don't understand this logic. So you claim you have debug boards which
>>> do not have battery, but define monitored-battery? Then these are wrong
>>> and fix them first.
>>
>> Actually our firmware treats the debug board as a "fake battery" rather then
>> a "no-battery" case.
>>
>> This is done to avoid triggering shutdown or trigger power/thermal related
>> mitigations to kick in from the HLOS (android) that is configured mainly for
>> battery-backed devices.
>>
>> Note that we can know if its a debug board, just by looking at the battery
>> ID resistance or the battery profile name in the power supply properties
>> for `qcom-battmgr-bat` in sysfs.
>>
>> However, the problem started with the boards that are battery-less and
>> unfortunetely used the same debug board batt ID resistance value, so from
>> the firmware side the batteryless board is also seen same as a board with
>> debug-board connected.

Bumping up my other reply, are there other markers that could interpreted,
perhaps design_capacity = 0?

Or are those values reported based on hardcoded data which is chosen
through the batt_id values you mentioned?

>> Since firmware does not have a way to dynamically tell if it on a
>> debug-board powered device or a DCIN powered device, We are required to
>> add this new DT property.
> 
> Neither debug-board powered device nor battery-less will have
> monitored-battery, thus again, why lack of that property cannot tell you
> what you need?

A device with a battery will not have a monitored-battery either

Konrad