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

[Rong Zhang <i@rong.moe>]

Hi Josh,

On Sat, 2026-11-07 at 12:49 -0800, Josh Triplett wrote:
> On Sat, Nov 07, 2026 at 07:45:12PM +0800, Rong Zhang wrote:
> > Hi Josh,
> > 
> > On Fri, 2026-11-06 at 15:48 -0800, Josh Triplett wrote:
> > > On Sat, Nov 07, 2026 at 04:48:44AM +0800, Rong Zhang wrote:
> > > > The term "unsafe LED" exists because LEDs are write-only for software and
> > > > fire-and-forget for the EC. By taking the control of an unsafe LED, e.g.,
> > > > attaching an LED trigger, any warning signal from the EC can no longer be
> > > > displayed by the LED.
> > > > 
> > > > When it comes to battery LEDs, they are definitely unsafe to override.
> > > > After all, batteries are dangerous things when they malfuction. Thus, I
> > > > don't think it's suitable to enable it for all users.
> > > 
> > > Choosing to not report "charging" vs "full" vs "not charging" via LEDs
> > > (as opposed to on-screen indicators) is not in itself dangerous. If the
> > > EC has something like "battery is damaged/overheating/exploding" to
> > > report, it had better do that by some more effective means than blinking
> > > an LED, or the message is going to be lost.
> > 
> > This is not in contradiction to the fact that blinking an LED is crucial.
> 
> Something can simultaneously be crucial and completely ineffective. As
> mentioned elsewhere in the thread, "immediate shutdown" would be an
> improvement. Bonus if a message appears on the screen for a few seconds
> so the user has some idea what's going on, but whether the OS handles
> that or not, the shutdown would be an improvement.
> 
> > > I can't comment on what *every* ThinkPad EC would do, but at least on
> > > this X1 Carbon Gen 11, 
> > 
> > That's the whole issue. The patch unlocks charging LEDs on all models,
> > while your ThinkPad can't speak on behalf of other models.
> 
> If that is the primary concern, would you accept a DMI-identity-based
> allowlist?

I don't think you need this if we take the module parameter approach.
Usually we don't want to introduce a infinitely-growing DMI quirk table
for some niche use cases.

Meanwhile, I can't totally trust your LLM's conclusion. The ACPI part may
be correct as understanding decompiled ASL code is not hard for an LLM,
while reverse-engineering EC firmware is completely on another dimension.

Thanks,
Rong

> 
> - Josh