Arch Linux

jelly

Administrator

From: /dev/null

Registered: 2008-06-10

Posts: 716

Looking for kernel patch testers for Panasonic laptops

I have been working on converting existing platform x86 drivers to a unified charge_types API with the goal to allow users to easily set battery charge limits from your Desktop Environment or a script.

Back in the day there was no standard API for preserving your battery health so every laptop driver would have its own custom file "battery_care_limit" or "eco_mode" etc.
So far I have converted the ideapad driver over to the new API, but I would want to convert everyone of them without having to buy even more laptops :-)

If you have a Panasonic laptop with the following file in sysfs:

/sys/devices/platform/panasonic/eco_mode

And would be happy to test a kernel, then feel free to contact me via email.

---

dotfiles

shishen

Member

Registered: 2026-08-07

Posts: 2

Re: Looking for kernel patch testers for Panasonic laptops

Hi Jelly, I sent you an email through the forum contact form with CF-SV8 panasonic-laptop eco_mode test results.

Short summary: my CF-SV8 (CFSV8-2 / CF-SV8RDEETW) exposes the eco_mode sysfs node, but reading returns EIO and writing 1 returns EINVAL. dmesg reports

\_SB.ECWR evaluation failed.

I can resend the details or test patches if useful.

The machine has MAT0019/HKEY, but I could not find an ECWR method in the ACPI dump.

Last edited by shishen (2026-08-07 07:31:13)

ReDress

Banned

From: Nairobi

Registered: 2024-11-30

Posts: 467

Website

Re: Looking for kernel patch testers for Panasonic laptops

Sometimes ACPI points into PCI configuration space. Or, rather, I device I worked with / on had been doing that.

I'm not sure that is the case in this scenario but surely it would be a good idea to make sure the same is or is not happening.

shishen

Member

Registered: 2026-08-07

Posts: 2

Re: Looking for kernel patch testers for Panasonic laptops

Sometimes ACPI points into PCI configuration space. Or, rather, I device I worked with / on had been doing that.

I'm not sure that is the case in this scenario but surely it would be a good idea to make sure the same is or is not happening.

Thanks. I audited that path. For the values we were looking at, ER09 and ERB8 are declared under OperationRegion(ECR, EmbeddedControl, Zero, 0xFF),
so the SINF[0x0A] read path and SSET(0x80) test path are EC-backed, not PCI_Config.

There is still firmware indirection when ECST == 0: EC81/EC85 go through ASRV(0x11, ...), so I agree it is not safe to assume every related control is plain EC register access.
I also checked the PCI/SystemMemory regions I could find; the obvious SystemMemory region in the reduced output is the USB-C/UCSI device, not battery eco control.

Last edited by shishen (2026-08-08 05:01:33)