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

[Rakesh Kota]

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?

regards
Rakesh Kota