From: "Henrique de Moraes Holschuh" <hmh@hmh.eng.br>
To: "Rong Zhang" <i@rong.moe>, "Josh Triplett" <josh@joshtriplett.org>
Cc: "Mark Pearson" <mpearson-lenovo@squebb.ca>,
"Derek J. Clark" <derekjohn.clark@gmail.com>,
"Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"Thinkpad-acpi devel ML" <ibm-acpi-devel@lists.sourceforge.net>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] platform/x86: tpacpi: Mark charging LEDs as safe
Date: Sat, 07 Nov 2026 09:34:03 -0300 [thread overview]
Message-ID: <c70af6c5-3d95-44c5-8f3f-b014178234c9@app.fastmail.com> (raw)
In-Reply-To: <20d824152b1a889b636ef9877b4d1a8e06dcf460.camel@rong.moe>
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.
--
Henrique Holschuh
prev parent reply other threads:[~2026-11-07 12:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 19:24 Josh Triplett
2026-11-06 20:48 ` Rong Zhang
2026-11-06 23:48 ` Josh Triplett
2026-11-07 11:45 ` Rong Zhang
2026-11-07 12:34 ` Henrique de Moraes Holschuh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c70af6c5-3d95-44c5-8f3f-b014178234c9@app.fastmail.com \
--to=hmh@hmh.eng.br \
--cc=derekjohn.clark@gmail.com \
--cc=hansg@kernel.org \
--cc=i@rong.moe \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpearson-lenovo@squebb.ca \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®