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

[Rakesh Kota]

On Thu, Jul 16, 2026 at 06:54:36PM -0500, Bjorn Andersson wrote:
> 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.
>
Thank you for the suggestion, Bjorn!

Yes, qcom,battmgr-interfaces = "ac", "usb"; sounds like the right
approach — it cleanly covers all use cases.

@Krzysztof Kozlowski, could you please share your thoughts on this direction? Would
you be okay with adding this as an optional DT property?

regards
Rakesh Kota

> Regards,
> Bjorn
>