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

[Rakesh Kota]

On Fri, Jul 03, 2026 at 11:16:59AM +0200, Krzysztof Kozlowski wrote:
> 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.


can we have 2 supplies added - (fake) battery and mains?  if we detect 10K bat id?
since mobile/production platforms share the same firmware and driver code,
the debug board still requires a fake battery registration to keep the common
code path functional. In that scenario, should we register both the main power
supply (DC adapter) and a fake battery, so the shared code continues to work
correctly without requiring platform-specific divergence?

regards
Rakesh Kota