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

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

[Rakesh Kota]

On batteryless boards powered by 12V DC adapters, registering the
power supply as BATTERY causes userspace to incorrectly trigger
battery power-saving sequences.

This series introduces a new "qcom,batteryless" boolean DT property.
When present, the driver registers the power supply as
POWER_SUPPLY_TYPE_MAINS instead, accurately reflecting the hardware.

Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Rakesh Kota (2):
      dt-bindings: soc: qcom: pmic-glink: Document batteryless property
      power: supply: qcom_battmgr: Add support batteryless boards as MAINS

 .../bindings/soc/qcom/qcom,pmic-glink.yaml         |  8 ++++
 drivers/power/supply/qcom_battmgr.c                | 47 +++++++++++++++++++++-
 2 files changed, 54 insertions(+), 1 deletion(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260518-add_dc_in_support-f3f3c4dac6e8

Best regards,
-- 
Rakesh Kota <rakesh.kota@oss.qualcomm.com>

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

[Rakesh Kota]

Document the "qcom,batteryless" boolean device tree property
for the PMIC Glink battery manager node.

When this property is present, the battery manager driver registers
the power supply as POWER_SUPPLY_TYPE_MAINS instead of BATTERY.
This is intended for 12V DC adapters, where presenting the supply
as a battery would cause userspace to incorrectly trigger battery
power-saving sequences.

Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
index ff01d2f3ee5be18e404591e3f0382ff2b3f7d168..5f7b90d37ea09d9aacff463b2ff4b76d218bbeac 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -72,6 +72,14 @@ properties:
       - const: charge_limit_end
       - const: charge_limit_delta
 
+  qcom,batteryless:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      When present, the battery manager registers the power supply as
+      POWER_SUPPLY_TYPE_MAINS instead of BATTERY. This is intended for
+      12V DC adapters, where exposing the supply as a battery would
+      incorrectly trigger userspace battery power-saving sequences.
+
 patternProperties:
   '^connector@\d$':
     $ref: /schemas/connector/usb-connector.yaml#

-- 
2.34.1

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

[Krzysztof Kozlowski]

On 18/05/2026 15:49, Rakesh Kota wrote:
> Document the "qcom,batteryless" boolean device tree property
> for the PMIC Glink battery manager node.
> 
> When this property is present, the battery manager driver registers
> the power supply as POWER_SUPPLY_TYPE_MAINS instead of BATTERY.
> This is intended for 12V DC adapters, where presenting the supply
> as a battery would cause userspace to incorrectly trigger battery
> power-saving sequences.
> 
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> index ff01d2f3ee5be18e404591e3f0382ff2b3f7d168..5f7b90d37ea09d9aacff463b2ff4b76d218bbeac 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> @@ -72,6 +72,14 @@ properties:
>        - const: charge_limit_end
>        - const: charge_limit_delta
>  
> +  qcom,batteryless:
> +    $ref: /schemas/types.yaml#/definitions/flag
> +    description:
> +      When present, the battery manager registers the power supply as
> +      POWER_SUPPLY_TYPE_MAINS instead of BATTERY. This is intended for

You described the desired Linux feature or behavior, not the actual
hardware. The bindings are about the latter, so instead you need to
rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.

And isn't lack of monitored battery property enough to indicate that?

Best regards,
Krzysztof

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

[Rakesh Kota]

On Mon, May 18, 2026 at 05:27:48PM +0200, Krzysztof Kozlowski wrote:
> On 18/05/2026 15:49, Rakesh Kota wrote:
> > Document the "qcom,batteryless" boolean device tree property
> > for the PMIC Glink battery manager node.
> > 
> > When this property is present, the battery manager driver registers
> > the power supply as POWER_SUPPLY_TYPE_MAINS instead of BATTERY.
> > This is intended for 12V DC adapters, where presenting the supply
> > as a battery would cause userspace to incorrectly trigger battery
> > power-saving sequences.
> > 
> > Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> > ---
> >  Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> > index ff01d2f3ee5be18e404591e3f0382ff2b3f7d168..5f7b90d37ea09d9aacff463b2ff4b76d218bbeac 100644
> > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> > @@ -72,6 +72,14 @@ properties:
> >        - const: charge_limit_end
> >        - const: charge_limit_delta
> >  
> > +  qcom,batteryless:
> > +    $ref: /schemas/types.yaml#/definitions/flag
> > +    description:
> > +      When present, the battery manager registers the power supply as
> > +      POWER_SUPPLY_TYPE_MAINS instead of BATTERY. This is intended for
> 
> You described the desired Linux feature or behavior, not the actual
> hardware. The bindings are about the latter, so instead you need to
> rephrase the property and its description to match actual hardware
> capabilities/features/configuration etc.
>

Thanks for the feedback! We'll update the description to reflect the
actual hardware capability rather than the Linux behavior in next patch.

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

regards
Rakesh
> 
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

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.

Best regards,
Krzysztof

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

[Konrad Dybcio]

On 5/19/26 12:35 PM, 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.

I don't think any pmic-glink device defines a monitored-battery node

The firmware is in full control of the battery charger (maybe with the
exception of some coordination with ECs on some laptops and maybe if
the vendor has some very in-depth custom charging hw, but that's
educated guesses)

Konrad

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

[Krzysztof Kozlowski]

On 19/05/2026 12:47, Konrad Dybcio wrote:
> On 5/19/26 12:35 PM, 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.
> 
> I don't think any pmic-glink device defines a monitored-battery node
> 
> The firmware is in full control of the battery charger (maybe with the
> exception of some coordination with ECs on some laptops and maybe if
> the vendor has some very in-depth custom charging hw, but that's
> educated guesses)

If you are saying that monitored-battery is not applicable here, then it
feels like "battery-less" is not applicable as well.

Best regards,
Krzysztof

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

[Kamal Wadhwa]

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.

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.

Regards,
Kamal


> 
> Best regards,
> Krzysztof
> 

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

[Krzysztof Kozlowski]

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

And no, you are not required to add a new DT property. Every wrong
property was also justified like that...

Best regards,
Krzysztof

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

[Konrad Dybcio]

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?

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

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

[Krzysztof Kozlowski]

On 21/05/2026 10:46, Konrad Dybcio wrote:
> On 5/21/26 9:20 AM, Krzysztof Kozlowski wrote:
>>> 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
But why? If for such device property "no battery" is suitable, then for
me "monitored-battery" is suitable as well. IOW, if you say that having
a property describing batter is not a accurate hardware property here,
then neither saying "no battery" is, because no batter is basically some
sort of battery (just like empty set is still a set, empty array is
still an array).

Best regards,
Krzysztof

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

[PATCH 2/2] power: supply: qcom_battmgr: Add support batteryless boards as MAINS

[Rakesh Kota]

Add support for the "qcom,batteryless" device tree property.
When this boolean property is present, the driver registers the power
supply as POWER_SUPPLY_TYPE_MAINS instead of BATTERY. This prevents
userspace from triggering battery power-saving sequences when using
powered by 12V adapters.

Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
 drivers/power/supply/qcom_battmgr.c | 47 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
index 490137a23d00e97a9e6ced21d1e66fe637db6c9d..35d266375d8c46b161a64f9c2a8c6054dc2211de 100644
--- a/drivers/power/supply/qcom_battmgr.c
+++ b/drivers/power/supply/qcom_battmgr.c
@@ -332,6 +332,7 @@ struct qcom_battmgr {
 	struct qcom_battmgr_wireless wireless;
 
 	struct work_struct enable_work;
+	bool batteryless;
 
 	/*
 	 * @lock is used to prevent concurrent power supply requests to the
@@ -930,6 +931,47 @@ static const struct power_supply_desc sm8550_bat_psy_desc = {
 	.property_is_writeable = qcom_battmgr_bat_is_writeable,
 };
 
+static int qcom_battmgr_dcin_get_property(struct power_supply *psy,
+					  enum power_supply_property psp,
+					  union power_supply_propval *val)
+{
+	struct qcom_battmgr *battmgr = power_supply_get_drvdata(psy);
+	int ret;
+
+	if (!battmgr->service_up)
+		return -EAGAIN;
+
+	ret = qcom_battmgr_bat_sm8350_update(battmgr, psp);
+	if (ret < 0)
+		return ret;
+
+	switch (psp) {
+	case POWER_SUPPLY_PROP_STATUS:
+		val->intval = battmgr->status.status;
+		break;
+	case POWER_SUPPLY_PROP_PRESENT:
+		val->intval = battmgr->info.present;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static const enum power_supply_property dcin_props[] = {
+	POWER_SUPPLY_PROP_STATUS,
+	POWER_SUPPLY_PROP_PRESENT,
+};
+
+static const struct power_supply_desc dcin_psy_desc = {
+	.name = "qcom-battmgr-dcin",
+	.type = POWER_SUPPLY_TYPE_MAINS,
+	.properties = dcin_props,
+	.num_properties = ARRAY_SIZE(dcin_props),
+	.get_property = qcom_battmgr_dcin_get_property,
+};
+
 static int qcom_battmgr_ac_get_property(struct power_supply *psy,
 					enum power_supply_property psp,
 					union power_supply_propval *val)
@@ -1652,6 +1694,7 @@ static int qcom_battmgr_probe(struct auxiliary_device *adev,
 	mutex_init(&battmgr->lock);
 	init_completion(&battmgr->ack);
 
+	battmgr->batteryless = device_property_read_bool(dev, "qcom,batteryless");
 	match = of_match_device(qcom_battmgr_of_variants, dev->parent);
 	if (match)
 		battmgr->variant = (unsigned long)match->data;
@@ -1690,7 +1733,9 @@ static int qcom_battmgr_probe(struct auxiliary_device *adev,
 			return dev_err_probe(dev, PTR_ERR(battmgr->wls_psy),
 					     "failed to register wireless charing power supply\n");
 	} else {
-		if (battmgr->variant == QCOM_BATTMGR_SM8550)
+		if (battmgr->batteryless)
+			psy_desc = &dcin_psy_desc;
+		else if (battmgr->variant == QCOM_BATTMGR_SM8550)
 			psy_desc = &sm8550_bat_psy_desc;
 		else
 			psy_desc = &sm8350_bat_psy_desc;

-- 
2.34.1

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

[Konrad Dybcio]

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?

Konrad

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

[Rakesh Kota]

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.

regards
Rakesh
> Konrad

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

[Konrad Dybcio]

On 5/19/26 8:59 AM, 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.

Does the firmware report anything obvious that would point to this not
being a battery, e.g. design_capacity = 0?

Konrad

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

[Rakesh Kota]

On Tue, May 19, 2026 at 12:58:06PM +0200, Konrad Dybcio wrote:
> On 5/19/26 8:59 AM, 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.
> 
> Does the firmware report anything obvious that would point to this not
> being a battery, e.g. design_capacity = 0?
>
No. The firmware identifies the 10k Batt-ID resistor (which mimics a
physical battery) and hardcodes capacity and status values to
ensure boot stability. It does not report 0 capacity, as doing so would
trigger an immediate system shutdown.

regards
Rakesh
> Konrad