Re: [PATCH] platform/x86: tpacpi: Mark charging LEDs as safe

[Rong Zhang]

Hi Henrique,

Thanks a lot for the context and opinions.

On Sat, 2026-11-07 at 09:34 -0300, Henrique de Moraes Holschuh wrote:
> Eh, I better voice something about this...
> 
> 1. The EC does use the battery led for alarms, and it also has specific high urgency events when it thinks the thing will catch fire or going to forcefully cut power very soon, although this was a relatively later enhancement.
> 
> Thinkpad ACPI is supposed to log a critical warning and it should attempt to initiate a system shutdown (power off) if it ever receives battery emergency alerts.  I was explicitly advised to do it this way by Lenovo bios engineering, in private, a long time ago.
> 
> 2. Module parameters are the way I dealt with this kind of thing in the past, especially if they are not mutable at runtime.  It is vastly better than debugfs for this kind of thing IMHO and the fan control was implemented that way.
> 
> But the default must be the safer behavior.
> 
> > OTOH, CONFIG_THINKPAD_ACPI_UNSAFE_LEDS should taint the kernel on the
> > very beginning.
> 
> I don't think tainting makes sense as long as it is something you either have to compile for and a distro would never do so as a default, or something you need to load the module with an explicit parameter set.  It will not cause system instability, unlike, say, poking around the EC registers directly.
> 
> A module parameter is a decent compromise IMO: 
> Debugfs is too reachable for userspace to mess with without actually doing an informed opt-in.  People respect module parameters a lot more.

Using a module parameter also makes sense. I will resubmit my patch [1]
to adopt the approach, probably the next week.

Speaking of tainting the kernel, I would still like to hear Mark's
option. Note that a module parameter may also taint the kernel as long as
module_param_unsafe() is used, and multiple pdx86 drivers have taken the
advantage of it.

[1]: 20261107-tpacpi-debugfs-unlock-unsafe-led-v1-1-69b1f1e10c2f@xxxxxxxx

Thanks,
Rong