Re: [PATCH 1/2] dt-bindings: soc: qcom: pmic-glink: Document batteryless property

[Rakesh Kota]

On Thu, May 21, 2026 at 10:46:15AM +0200, Konrad Dybcio wrote:
> On 5/21/26 9:20 AM, Krzysztof Kozlowski wrote:
> > On 21/05/2026 09:13, Kamal Wadhwa wrote:
> >> On Tue, May 19, 2026 at 12:35:13PM +0200, Krzysztof Kozlowski wrote:
> >>> On Tue, May 19, 2026 at 01:55:26PM +0530, Rakesh Kota wrote:
> >>>>
> >>>>> And isn't lack of monitored battery property enough to indicate that?
> >>>>
> >>>> Regarding monitored-battery — its absence alone isn't sufficient. The
> >>>> BATT_ID line on debug boards is pulled to ~10kΩ, which is used during
> >>>> development phase where some battery properties are still present. The
> >>>> same ~10kΩ value is also used on some genuinely battery-less production
> >>>> platforms where no battery properties exist, making auto-detection
> >>>> unreliable. Hence the need for an explicit DT property to identify
> >>>> hardware platforms where no battery populated. 
> >>>
> >>> I don't understand this logic. So you claim you have debug boards which
> >>> do not have battery, but define monitored-battery? Then these are wrong
> >>> and fix them first.
> >>
> >> Actually our firmware treats the debug board as a "fake battery" rather then
> >> a "no-battery" case.
> >>
> >> This is done to avoid triggering shutdown or trigger power/thermal related
> >> mitigations to kick in from the HLOS (android) that is configured mainly for
> >> battery-backed devices.
> >>
> >> Note that we can know if its a debug board, just by looking at the battery
> >> ID resistance or the battery profile name in the power supply properties
> >> for `qcom-battmgr-bat` in sysfs.
> >>
> >> However, the problem started with the boards that are battery-less and
> >> unfortunetely used the same debug board batt ID resistance value, so from
> >> the firmware side the batteryless board is also seen same as a board with
> >> debug-board connected.
> 
> Bumping up my other reply, are there other markers that could interpreted,
> perhaps design_capacity = 0?
> 
> Or are those values reported based on hardcoded data which is chosen
> through the batt_id values you mentioned?

Yes, that is correct. The firmware uses the Batt-ID (~10kΩ) to select
a profile with hardcoded data.

regards
Rakesh
> 
> >> Since firmware does not have a way to dynamically tell if it on a
> >> debug-board powered device or a DCIN powered device, We are required to
> >> add this new DT property.
> > 
> > Neither debug-board powered device nor battery-less will have
> > monitored-battery, thus again, why lack of that property cannot tell you
> > what you need?
> 
> A device with a battery will not have a monitored-battery either
> 
> Konrad