From: "Josh Triplett" <josh@joshtriplett.org>
To: "Rong Zhang" <i@rong.moe>
Cc: "Mark Pearson" <mpearson-lenovo@squebb.ca>,
"Henrique de Moraes Holschuh" <hmh@hmh.eng.br>,
"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,
ibm-acpi-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] platform/x86: tpacpi: Mark charging LEDs as safe
Date: Sat, 07 Nov 2026 13:42:36 -0800 [thread overview]
Message-ID: <b2ca4d95-7b66-4a8a-8e47-84ab0e052bd1@app.fastmail.com> (raw)
In-Reply-To: <5219f8fbd637a3b2603ffcca3e6cd624db982aba.camel@rong.moe>
Rong Zhang wrote:
> On Sat, 2026-11-07 at 12:49 -0800, Josh Triplett wrote:
>> 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.
The module parameter approach seems fine, as long as it doesn't taint the
kernel to use.
> Meanwhile, I can't totally trust your LLM's conclusion.
Extremely valid.
> 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.
As it turns out, the EC firmware appeared to be unencrypted ARM Thumb code,
and LLMs are pretty good at disassembling these days, too. But still, full
support for "can't totally trust". The ideal solution would be if someone
from Lenovo could confirm the conclusion.
prev parent reply other threads:[~2026-11-07 21:42 UTC|newest]
Thread overview: 10+ 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
2026-11-07 15:25 ` Rong Zhang
2026-11-07 20:55 ` Rong Zhang
2026-11-07 20:49 ` Josh Triplett
2026-11-07 21:08 ` Rong Zhang
2026-11-07 21:42 ` Josh Triplett [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=b2ca4d95-7b66-4a8a-8e47-84ab0e052bd1@app.fastmail.com \
--to=josh@joshtriplett.org \
--cc=derekjohn.clark@gmail.com \
--cc=hansg@kernel.org \
--cc=hmh@hmh.eng.br \
--cc=i@rong.moe \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=ilpo.jarvinen@linux.intel.com \
--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®