[Bug 221065] ideapad_acpi: unexpected charge_types spam on Yoga Pro 7 14ASP9

bugzilla-daemon
2026-02-09T12:11:41Z

--- Comment #2 from Rong Zhang (i@rong.moe) ---
Hi Raphael,

On Mon, 2026-02-09 at 07:50 +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=221065
>
> Bug ID: 221065
> Summary: ideapad_acpi: unexpected charge_types spam on Yoga Pro
> 7 14ASP9
> Product: Drivers
> Version: 2.5
> Hardware: AMD
> OS: Linux
> Status: NEW
> Severity: low
> Priority: P3
> Component: Platform_x86
> Assignee: drivers_platform_x86@kernel-bugs.osdl.org
> Reporter: rbitton@linux.com
> Regression: No
>
> Hi,
>
> I'm experiencing constant dmesg spam from ideapad_acpi on my Lenovo Yoga Pro
> 7
> 14ASP9:
>
> [ 733.997072] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast]
> and [Long_Life] are enabled

Please attach the full dmesg log along with the acpidump of your
device.

This error log is intended to remind users to write either Fast or
Long_Life to charge_types to break the dilemma. Could you check
/sys/kernel/debug/ideapad/status before and after writing into
charge_types?

> This started on 6.19.0 on both my distro's mainline kernel and the vanilla
> mainline kernel I compiled. The issue is not present in 6.18. It happens
> about
> every minute starting about a minute after boot regardless of if I'm charging
> or not.

In your case there was a userspace process reading charge_types every
minute and triggering the error log.

What process was it? Could you check with

sudo perf --no-pager ftrace -T ideapad_psy_ext_get_prop

to see its pid and find out what it is?

> Model: Lenovo Yoga Pro 7 14ASP9 (83HN)
> CPU: AMD Ryzen AI 9 365
> BIOS: PSCN17WW (up to date)
>
> The laptop appears to be reporting both Fast and Long_Life charge modes
> simultaneously, which the driver considers unexpected. Functionally
> everything
> works fine, including fast charging, but the log spam is excessive.

Did it stop charging at 60%/80%? That's what I got (i.e., both fast
charging and charge threshold) when I manually put my device into such
a state.

> Of note:
> zsh rbitton@rbitton-linux3 01:46 /sys/class/power_supply/BAT0 > cat
> /sys/class/power_supply/BAT*/charge_types
> [Fast] Standard Long_Life

Wait, I don't understand how this could happen. Reading charge_types
should have failed with -EINVAL when it ran into the error path. In
other words, you have already got out of the dilemma when reading
charge_types returns successfully. So at least it temporarily recovered
to an expected state when you read charge_types, but was somehow broken
by other things afterward...

Could you check `sudo lsmod | grep acpi_call'? Did you ever set up
anything abusing acpi_call?

> All attempts to fix it on my end have failed.Let me know if you need any
> additional information; I would be more than willing to test any fixes.

Could you try booting into a livecd (or a fresh installation) of your
distro with 6.19 kernel and monitoring any upcoming kmsg with `sudo
dmesg -w', then:

1. read charge_types
2. write Fast into charge_types
a. read charge_types
b. unplug and replug AC power
c. read charge_types
d. wait several minutes
e. read charge_types
3. write Standard into charge_types
repeat a-e
4. write Long_Life into charge_types
repeat a-e

And attach your observation in reply.

If the issue persist in fresh installation/livecd, the firmware on your
device may have its own thoughts (?!) and messes up charge modes on its
own.

Thanks,
Rong

> Thanks,
> Raphael Bitton