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

[Dmitry Baryshkov]

On Thu, May 21, 2026 at 12:43:41PM +0530, 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.

Which devices are using this resistance value? Can this be fixed by
resoldering the devices? Can we fix this by pushing this property into
the adsp_dtb.mbn and then using it for those affected devices only?

> 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.

No, you are not. It's just a solution that you are proposing. One of a
plenty. Please start by describing the problem:

Device BigVendor some-EVK v1.23 has a hardware flow, the soldered in
resistance makes ADSP firmware emulate a fake battery rather than
completely ignoring the battery when reporting PSY properties. This is
confusing for the users of that EVK, which are assumed to be not able to
resolder 0203-size resistance, etc.

-- 
With best wishes
Dmitry