[PATCH] power: supply: pf1550: enable charging when battery profile exists

[PATCH] power: supply: pf1550: enable charging when battery profile exists

[raoxu]

From: Xu Rao <raoxu@uniontech.com>

PF1550 starts in charger mode 1, where charging is disabled. The driver
comment says that mode 2 should be selected for applications using a
battery, but the condition is inverted: PF1550_CHG_BAT_ON is written only
when power_supply_get_battery_info() fails.

Consequently, a board with a valid monitored-battery profile is left in
the default charger-off mode, while a board without battery information
enables charging with the fallback voltage.

Select mode 2 when battery information is available. Also release the
battery-info objects after use.

Fixes: 4b6b6433a97d ("power: supply: pf1550: add battery charger support")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
---
 drivers/power/supply/pf1550-charger.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/power/supply/pf1550-charger.c b/drivers/power/supply/pf1550-charger.c
index 41036f4cb64a..f698becd662a 100644
--- a/drivers/power/supply/pf1550-charger.c
+++ b/drivers/power/supply/pf1550-charger.c
@@ -514,7 +514,10 @@ static int pf1550_reg_init(struct pf1550_charger *chg)
 	 * a battery. The other supported mode is mode 2, the charger is turned
 	 * on to charge a battery when present.
 	 */
-	if (power_supply_get_battery_info(chg->charger, &info)) {
+	ret = power_supply_get_battery_info(chg->charger, &info);
+	if (!ret) {
+		power_supply_put_battery_info(chg->charger, info);
+
 		ret = regmap_write(chg->pf1550->regmap,
 				   PF1550_CHARG_REG_CHG_OPER,
 				   PF1550_CHG_BAT_ON);
@@ -540,10 +543,12 @@ static void pf1550_dt_parse_dev_info(struct pf1550_charger *chg)
 				     &chg->thermal_regulation_temp))
 		chg->thermal_regulation_temp = PF1550_DEFAULT_THERMAL_TEMP;

-	if (power_supply_get_battery_info(chg->charger, &info))
+	if (power_supply_get_battery_info(chg->charger, &info)) {
 		chg->constant_volt = PF1550_DEFAULT_CONSTANT_VOLT;
-	else
+	} else {
 		chg->constant_volt = info->constant_charge_voltage_max_uv;
+		power_supply_put_battery_info(chg->charger, info);
+	}
 }

 static int pf1550_charger_probe(struct platform_device *pdev)
--
2.50.1

Re: [PATCH] power: supply: pf1550: enable charging when battery profile exists

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Calling power_supply_put_battery_info() on a static battery profile triggers a devm_kfree() WARN_ON.

Pre-existing issues:
- [High] Missing device tree property leads to probe failure due to -EINVAL being cast to u32 and failing bounds checks.
--

--- Patch [1]: [PATCH] power: supply: pf1550: enable charging when battery profile exists ---
commit f509c83fb1ae8cc54a888243d6c3052c45c3c791
Author: Xu Rao <raoxu@uniontech.com>

power: supply: pf1550: enable charging when battery profile exists

This commit selects mode 2 for the PF1550 charger when a battery profile is
available, allowing it to charge instead of remaining in the default off mode.
It also adds calls to release the battery-info objects after use.

Cc: stable@vger.kernel.org

> diff --git a/drivers/power/supply/pf1550-charger.c b/drivers/power/supply/pf1550-charger.c
> --- a/drivers/power/supply/pf1550-charger.c
> +++ b/drivers/power/supply/pf1550-charger.c

[ ... ]

> @@ -540,10 +543,12 @@ static void pf1550_dt_parse_dev_info(struct pf1550_charger *chg)
>  				     &chg->thermal_regulation_temp))
>  		chg->thermal_regulation_temp = PF1550_DEFAULT_THERMAL_TEMP;
>  
> -	if (power_supply_get_battery_info(chg->charger, &info))
> +	if (power_supply_get_battery_info(chg->charger, &info)) {
>  		chg->constant_volt = PF1550_DEFAULT_CONSTANT_VOLT;
> -	else
> +	} else {
>  		chg->constant_volt = info->constant_charge_voltage_max_uv;

[Severity: High]
This is a pre-existing issue, but does assigning this value directly without 
validation cause the probe to fail if the device tree omits the optional 
constant-charge-voltage-max-microvolt property?

In power_supply_get_battery_info(), constant_charge_voltage_max_uv is 
initialized to -EINVAL. Since chg->constant_volt is a u32, the -EINVAL value 
underflows to a very large unsigned number.

When pf1550_set_constant_volt() later evaluates this out-of-bounds value 
against its allowed range, it looks like it will unconditionally reject it 
and abort the driver probe.

> +		power_supply_put_battery_info(chg->charger, info);

[Severity: High]
Will calling this on a static battery profile trigger a devm_kfree() warning?

If the device tree specifies a static battery profile (like a
samsung,eb425161la battery), power_supply_get_battery_info() returns a
pointer to the statically allocated samsung_sdi_batteries array. 

Because this array resides in the .data section rather than .rodata, when 
power_supply_put_battery_info() attempts to free it:

power_supply_core.c:power_supply_put_battery_info()
    devm_kfree(&psy->dev, info);

The is_kernel_rodata() check bypasses, and the devres lookup fails, resulting 
in a warning stack trace during probe.

> +	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/D5A5255CD2B683AC+20260724090341.297438-1-raoxu@uniontech.com?part=1