Re: [PATCH 0/2] qcom_battmgr: Add batteryless DC-adapter MAINS support

[Krzysztof Kozlowski]

On 03/07/2026 11:13, Rakesh Kota wrote:
> On Thu, Jul 02, 2026 at 01:28:35PM +0200, Krzysztof Kozlowski wrote:
>> On 02/07/2026 13:17, Rakesh Kota wrote:
>>> On Tue, Jun 30, 2026 at 04:16:13PM +0200, Konrad Dybcio wrote:
>>>> On 5/22/26 12:56 AM, Bjorn Andersson wrote:
>>>>> On Tue, May 19, 2026 at 12:29:38PM +0530, Rakesh Kota wrote:
>>>>>> On Mon, May 18, 2026 at 04:36:32PM +0200, Konrad Dybcio wrote:
>>>>>>> On 5/18/26 3:49 PM, Rakesh Kota wrote:
>>>>>>>> On batteryless boards powered by 12V DC adapters, registering the
>>>>>>>> power supply as BATTERY causes userspace to incorrectly trigger
>>>>>>>> battery power-saving sequences.
>>>>>>>
>>>>>>> Does battman really offer no way of differentiating whether a battery
>>>>>>> is *actually* present in such cases?
>>>>>>>
>>>>>>> What boards are affected?
>>>>>>>
>>>>>> Currently, batteryless support is only implemented for the
>>>>>> qcs6490-rb3gen2(Kodiak) board.
>>>>>>
>>>>>
>>>>> What do you mean?
>>>>>
>>>>> Are you saying that the pmic_glink firmware in Kodiak has a one-off hack
>>>>> that no other implementation of this firmware has?
>>>>>
>>>>> My Lenovo IdeaCentre (hamoa) doesn't have battery, what should I do now?
>>>>
>>>> I was going through my inbox.
>>>> This remains unanswered, and I don't see the discussion progressing
>>>> without resolving this.
>>>>
>>> To clarify — there is no platform-side hack involved. The Kodiak board
>>> has a batteryless variant, but the pmic_glink firmware provides no way
>>> to distinguish whether a battery is physically present or not. Since
>>> this can't be determined from firmware, we introduced a DT-based
>>> property to describe the hardware configuration explicitly.
>>>
>>> This is not Kodiak-specific — any batteryless board, including hamoa,
>>> can use the same DT property to avoid incorrect BATTERY registration
>>
>> Unfortunately the answer might be: fix your firmware. Since your
>> firmware is the interface and we do not expose battery in DT, then you
>> do not get additional properties. You made conscious design choice of
>> abstracting some things in the firmware, so you do control that part of
>> the software stack. If you make one choice, it might lead to other, like
>> rejecting such properties.
>>
> 
> This is a hardware limitation — both the debug board and batteryless
> platform use the same Batt_ID resistor (10K), so the firmware has no way
> to distinguish between the two at runtime. There is nothing to fix on
> the firmware side.
> 
> Given this, would a new compatible string (e.g.,qcom,pmic-glink-batteryless)
> be preferred over a DT property, or do you have another suggestion?

Debug board is not a end device, thus you basically have only one real
use case: battery less. Treat everything that.

Best regards,
Krzysztof