[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

[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 1/2] dt-bindings: soc: qcom: pmic-glink: Document batteryless property

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The device tree binding description references Linux-specific subsystem constants and dictates OS software behavior instead of strictly describing the hardware.
--

commit 27eac983fdf61301b30bef6fc60e922a67eecbbd
Author: Rakesh Kota <rakesh.kota@oss.qualcomm.com>

dt-bindings: soc: qcom: pmic-glink: Document batteryless property

This commit documents a new boolean property, qcom,batteryless, for the
PMIC Glink battery manager node. It is intended for systems powered by 12V
DC adapters rather than batteries.

> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> index ff01d2f3ee5be..5f7b90d37ea09 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.

This isn't a bug, but does this description reference Linux-specific
subsystem constants rather than strictly describing the hardware?

Device tree bindings are expected to be OS-agnostic and describe physical
hardware characteristics. The current text explicitly mentions
POWER_SUPPLY_TYPE_MAINS, BATTERY, and userspace behavior.

Could this be rephrased to focus on the physical hardware state, such as
indicating the system is powered by a continuous fixed DC source, instead
of dictating OS driver behavior?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518-add_dc_in_support-v1-0-31fbaa329879@oss.qualcomm.com?part=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 2/2] power: supply: qcom_battmgr: Add support batteryless boards as MAINS

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The new MAINS power supply exposes BATTERY properties (STATUS, PRESENT) instead of ONLINE, breaking userspace expectations.
- [Medium] The `qcom,batteryless` property is silently ignored on `SC8280XP` and `X1E80100` variants.
--

commit fd3fd36bafd15a4f0b8a90d2f6b2f13ff0fc3a3d
Author: Rakesh Kota <rakesh.kota@oss.qualcomm.com>

power: supply: qcom_battmgr: Add support batteryless boards as MAINS

This commit adds support for the qcom,batteryless device tree property to
register the power supply as a MAINS type instead of a BATTERY. This is
intended to prevent userspace from triggering battery power-saving sequences
on boards powered directly by adapters.

> diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
> index 490137a23d00e..35d266375d8c4 100644
> --- a/drivers/power/supply/qcom_battmgr.c
> +++ b/drivers/power/supply/qcom_battmgr.c
[ ... ]
> @@ -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,
> +};

Since dcin_psy_desc is registered as POWER_SUPPLY_TYPE_MAINS, should it
expose POWER_SUPPLY_PROP_ONLINE instead of POWER_SUPPLY_PROP_STATUS and
POWER_SUPPLY_PROP_PRESENT?

Userspace power managers typically expect MAINS power supplies to report their
active state via the ONLINE property.

If the firmware returns PRESENT=0 on a batteryless board, won't userspace
fail to recognize the AC adapter as an active power source and still trigger
power-saving or shutdown sequences?

[ ... ]
> @@ -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;

Does this bypass the qcom,batteryless property on SC8280XP and X1E80100
variants?

Looking at qcom_battmgr_probe(), the check for battmgr->batteryless is only
placed inside the else block which executes for SM8350 and SM8550:

drivers/power/supply/qcom_battmgr.c:qcom_battmgr_probe() {
...
	if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
	    battmgr->variant == QCOM_BATTMGR_X1E80100) {
		if (battmgr->variant == QCOM_BATTMGR_X1E80100)
			psy_desc = &x1e80100_bat_psy_desc;
		else
			psy_desc = &sc8280xp_bat_psy_desc;

		battmgr->bat_psy = devm_power_supply_register(dev, psy_desc, &psy_cfg);
...
	} else {
		if (battmgr->batteryless)
			psy_desc = &dcin_psy_desc;
...
}

If a board uses the SC8280XP or X1E80100 variant, won't it bypass this check
and unconditionally register the standard battery power supply?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518-add_dc_in_support-v1-0-31fbaa329879@oss.qualcomm.com?part=2

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 2/2] power: supply: qcom_battmgr: Add support batteryless boards as MAINS

[Rakesh Kota]

On Mon, May 18, 2026 at 03:10:12PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The new MAINS power supply exposes BATTERY properties (STATUS, PRESENT) instead of ONLINE, breaking userspace expectations.
> - [Medium] The `qcom,batteryless` property is silently ignored on `SC8280XP` and `X1E80100` variants.
> --
> 
> commit fd3fd36bafd15a4f0b8a90d2f6b2f13ff0fc3a3d
> Author: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> 
> power: supply: qcom_battmgr: Add support batteryless boards as MAINS
> 
> This commit adds support for the qcom,batteryless device tree property to
> register the power supply as a MAINS type instead of a BATTERY. This is
> intended to prevent userspace from triggering battery power-saving sequences
> on boards powered directly by adapters.
> 
> > diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
> > index 490137a23d00e..35d266375d8c4 100644
> > --- a/drivers/power/supply/qcom_battmgr.c
> > +++ b/drivers/power/supply/qcom_battmgr.c
> [ ... ]
> > @@ -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,
> > +};
> 
> Since dcin_psy_desc is registered as POWER_SUPPLY_TYPE_MAINS, should it
> expose POWER_SUPPLY_PROP_ONLINE instead of POWER_SUPPLY_PROP_STATUS and
> POWER_SUPPLY_PROP_PRESENT?
> 
> Userspace power managers typically expect MAINS power supplies to report their
> active state via the ONLINE property.
> 
> If the firmware returns PRESENT=0 on a batteryless board, won't userspace
> fail to recognize the AC adapter as an active power source and still trigger
> power-saving or shutdown sequences?
>
You are right. For POWER_SUPPLY_TYPE_MAINS, userspace expects ONLINE
to indicate the active state of the supply, not STATUS or PRESENT which
are battery-centric properties.

I will fixs this in the next version.

static enum power_supply_property dcin_props[] = {
	POWER_SUPPLY_PROP_ONLINE,
};

static int qcom_battmgr_dcin_get_property(struct power_supply *psy,
					  enum power_supply_property
					  psp,
					  union power_supply_propval *val)
{
	switch (psp) {
	case POWER_SUPPLY_PROP_ONLINE:
		val->intval = 1;
		break;
	default:
		return -EINVAL;
	}
return 0;
}

> [ ... ]
> > @@ -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;
> 
> Does this bypass the qcom,batteryless property on SC8280XP and X1E80100
> variants?
> 
> Looking at qcom_battmgr_probe(), the check for battmgr->batteryless is only
> placed inside the else block which executes for SM8350 and SM8550:
> 
> drivers/power/supply/qcom_battmgr.c:qcom_battmgr_probe() {
> ...
> 	if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
> 	    battmgr->variant == QCOM_BATTMGR_X1E80100) {
> 		if (battmgr->variant == QCOM_BATTMGR_X1E80100)
> 			psy_desc = &x1e80100_bat_psy_desc;
> 		else
> 			psy_desc = &sc8280xp_bat_psy_desc;
> 
> 		battmgr->bat_psy = devm_power_supply_register(dev, psy_desc, &psy_cfg);
> ...
> 	} else {
> 		if (battmgr->batteryless)
> 			psy_desc = &dcin_psy_desc;
> ...
> }
> 
> If a board uses the SC8280XP or X1E80100 variant, won't it bypass this check
> and unconditionally register the standard battery power supply?
> 
Currently, batteryless support is only implemented for the qcs6490-rb3gen2(Kodiak)
board. SC8280XP and X1E80100 variants do not have batteryless hardware
at this time, so there is no immediate concern.

We can revisit and extend this support when batteryless hardware becomes
available for those variants. That said, if you feel it's cleaner to
generalize the check now to avoid future leakage, happy to extend it —
please let us know your preference.

regards
Rakesh Kota
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518-add_dc_in_support-v1-0-31fbaa329879@oss.qualcomm.com?part=2

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 1/2] dt-bindings: soc: qcom: pmic-glink: Document batteryless property

[Rakesh Kota]

On Mon, May 18, 2026 at 01:59:57PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] The device tree binding description references Linux-specific subsystem constants and dictates OS software behavior instead of strictly describing the hardware.
> --
> 
> commit 27eac983fdf61301b30bef6fc60e922a67eecbbd
> Author: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> 
> dt-bindings: soc: qcom: pmic-glink: Document batteryless property
> 
> This commit documents a new boolean property, qcom,batteryless, for the
> PMIC Glink battery manager node. It is intended for systems powered by 12V
> DC adapters rather than batteries.
> 
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> > index ff01d2f3ee5be..5f7b90d37ea09 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.
> 
> This isn't a bug, but does this description reference Linux-specific
> subsystem constants rather than strictly describing the hardware?
> 
> Device tree bindings are expected to be OS-agnostic and describe physical
> hardware characteristics. The current text explicitly mentions
> POWER_SUPPLY_TYPE_MAINS, BATTERY, and userspace behavior.
> 
> Could this be rephrased to focus on the physical hardware state, such as
> indicating the system is powered by a continuous fixed DC source, instead
> of dictating OS driver behavior?
>
You're right, thanks for the feedback! Will update the description to be
OS-agnostic and focus on the physical hardware characteristics rather
than Linux subsystem internals and userspace in next patch.

regards
Rakesh
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518-add_dc_in_support-v1-0-31fbaa329879@oss.qualcomm.com?part=1

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

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

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

[Bjorn Andersson]

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?

Regards,
Bjorn

> regards
> Rakesh
> > Konrad

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