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

[Bjorn Andersson <andersson@kernel.org>]

On Thu, Jul 16, 2026 at 02:18:50PM +0530, Rakesh Kota wrote:
> 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?
> 

My Hamoa-based PC (desktop) currently reports: ac, battery, usb, and
wireless. I would expect that it reports on AC (or no battmgr
interfaces?).

If I understand what you're saying, the pmic-glink firmware is generic
across all Hamoa targets, so there is no configuration in that firmware
to differentiate between this and a laptop usecase?

Similarly, my Hamoa laptop doesn't have wireless charging, but you're
saying the pmic-glink firmware doesn't know about this - it just don't
get any input power on those pins?


I think this is similar to if we had a discrete charger block that we
describe in DeviceTree, we would somehow have to describe the
"configuration" of that component.

But I don't think you considered those other use cases. Perhaps this
should be an optional qcom,battmgr-interfaces = "ac", "usb" ...; taking
the list of interfaces that is actually implemented.

Regards,
Bjorn

> regards
> Rakesh Kota