From: "Mark Pearson" <mpearson-lenovo@squebb.ca>
To: "Rong Zhang" <i@rong.moe>, "Greg KH" <gregkh@linuxfoundation.org>
Cc: "Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Hans de Goede" <hansg@kernel.org>,
linux-usb@vger.kernel.org,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: typec: ucsi: acpi: Disable on devices with broken firmware
Date: Mon, 11 May 2026 19:11:10 -0400 [thread overview]
Message-ID: <06e5005d-8621-4031-b3a3-6fd735cebbd4@app.fastmail.com> (raw)
In-Reply-To: <c1df76ba422eebfc733f1c73655582804d0e2921.camel@rong.moe>
On Mon, May 11, 2026, at 3:12 PM, Rong Zhang wrote:
> (+CC Mark Pearson from Lenovo)
>
> Hi Greg,
>
> On Mon, 2026-05-11 at 20:25 +0200, Greg Kroah-Hartman wrote:
>> On Tue, May 12, 2026 at 01:59:34AM +0800, Rong Zhang wrote:
>> > Some Lenovo devices have broken firmware, which reads/writes half-valid-
>> > half-garbage values.
>>
>> How does this work with this firmware on other operating systems?
>>
>
> The timeout can hardly reached unless a bunch of events cause multiple
> drivers to compete for the same mutex simultaneously.
>
> If other operating systems' UCSI drivers don't send any command during
> power events, they won't suffer from the mutex acquisition timeout.
> Also, if other drivers on these operating systems don't touch the mutex
> on power events at all, their UCSI drivers should work well too.
>
> These operating systems' UCSI drivers are powered by undefined behavior
> (TM) in both cases.
>
>> What
>> is the odds of fixing the firmware?
>
> They are not Linux-certified devices, so Lenovo is very unlikely to fix
> the firmware unless it breaks Windows :(
>
> Quoting Mark Pearson's reply to the bugzilla thread:
>
> I can't promise anything - I don't have any official levers to pull for
> this platform I'm afraid (it is better to buy Linux supported/certified
> systems ;) )
>
> https://bugzilla.kernel.org/show_bug.cgi?id=221065#c38
>
>>
>> > Given that everything is broken, disable ucsi_acpi on these devices. The
>> > impact of disabling it is minimal, as Lenovo laptops usually have most
>> > USCI commands more or less stubbed, and the EC can always handles USB-C
>> > events on its own.
>> >
>> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=221065#c33
>> > Signed-off-by: Rong Zhang <i@rong.moe>
>> > ---
>> > drivers/usb/typec/ucsi/ucsi_acpi.c | 91 ++++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 91 insertions(+)
>> >
>> > diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
>> > index 6b92f296e985..7632b441d401 100644
>> > --- a/drivers/usb/typec/ucsi/ucsi_acpi.c
>> > +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
>> > @@ -155,6 +155,91 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
>> > { }
>> > };
>> >
>> > +static const struct dmi_system_id ucsi_acpi_broken_devices[] = {
>> > + /* Firmware reads/writes half-valid-half-garbage values. */
>> > +
>> > + /* BIOS: P1CN??WW */
>> > + {
>> > + .ident = "Lenovo IdeaPad 5 2-in-1 14AHP9",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83DR"),
>> > + },
>> > + },
>> > + {
>> > + .ident = "Lenovo IdeaPad 5 2-in-1 16AHP9",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83DS"),
>> > + },
>> > + },
>> > +
>> > + /* BIOS: R0CN??WW */
>> > + {
>> > + .ident = "Lenovo IdeaPad Slim 5 14AKP10",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83NJ"),
>> > + },
>> > + },
>> > + {
>> > + .ident = "Lenovo IdeaPad Slim 5 14AKP10",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83HX"),
>> > + },
>> > + },
>> > + {
>> > + .ident = "Lenovo IdeaPad Slim 5 16AKP10",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83HY"),
>> > + },
>> > + },
>> > +
>> > + /* BIOS: QXCN??WW */
>> > + {
>> > + .ident = "Lenovo Yoga 7 2-in-1 14AKP10",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83JR"),
>> > + },
>> > + },
>> > + {
>> > + .ident = "Lenovo Yoga 7 2-in-1 16AKP10",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83JU"),
>> > + },
>> > + },
>> > +
>> > + /* BIOS: LNCN??WW */
>> > + {
>> > + .ident = "Lenovo Yoga Pro 7 14ARP8",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83AU"),
>> > + },
>> > + },
>> > + {
>> > + .ident = "Lenovo Slim Pro 7 14ARP8",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83AX"),
>> > + },
>> > + },
>> > +
>> > + /* BIOS: PSCN??WW */
>> > + {
>> > + .ident = "Lenovo Yoga Pro 7 14ASP9",
>> > + .matches = {
>> > + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> > + DMI_MATCH(DMI_PRODUCT_NAME, "83HN"),
>> > + },
>> > + },
>> > + { }
>> > +};
>>
>> That is a lot of devices to exclude, are you sure that none of them will
>> ever work properly?
>
> Yes. I carefully checked all acpidumps for these devices provided by
> device owners who replied to the bugzilla thread, and confirmed that
> they all share the same UCSI-ACPI implementation.
>
> 83DR, 83HN, 83HY, 83AU, 83JR are owned by these device owners. Other
> devices share the same BIOS images (see comments in the match table), so
> I added them as well.
>
> Device owners also reported their dmesg dumps/snips with ucsi_acpi
> errors.
>
> As a reference, buggy ASL methods are shown as below.
>
> \_SB.PCI0.LPC0.EC0:
> Method (ECRD, 1, Serialized)
> {
> Local0 = Acquire (ECMT, 0x03E8)
> If ((Local0 == Zero))
> {
> If (ECAV)
> {
> Local1 = DerefOf (Arg0)
> Release (ECMT)
> Return (Local1)
> }
> Else
> {
> Release (ECMT)
> }
> }
>
> Return (Zero)
> }
>
> Method (ECWT, 2, Serialized)
> {
> Local0 = Acquire (ECMT, 0x03E8)
> If ((Local0 == Zero))
> {
> If (ECAV)
> {
> Arg1 = Arg0
> }
>
> Release (ECMT)
> }
> }
>
> \_SB.UBTC:
> Method (ECWR, 0, Serialized)
> {
> IO80 = 0xD0
> \_SB.PCI0.LPC0.EC0.ECWT (MGO0, RefOf (\_SB.PCI0.LPC0.EC0.MGO0))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO1, RefOf (\_SB.PCI0.LPC0.EC0.MGO1))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO2, RefOf (\_SB.PCI0.LPC0.EC0.MGO2))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO3, RefOf (\_SB.PCI0.LPC0.EC0.MGO3))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO4, RefOf (\_SB.PCI0.LPC0.EC0.MGO4))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO5, RefOf (\_SB.PCI0.LPC0.EC0.MGO5))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO6, RefOf (\_SB.PCI0.LPC0.EC0.MGO6))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO7, RefOf (\_SB.PCI0.LPC0.EC0.MGO7))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO8, RefOf (\_SB.PCI0.LPC0.EC0.MGO8))
> \_SB.PCI0.LPC0.EC0.ECWT (MGO9, RefOf (\_SB.PCI0.LPC0.EC0.MGO9))
> \_SB.PCI0.LPC0.EC0.ECWT (MGOA, RefOf (\_SB.PCI0.LPC0.EC0.MGOA))
> \_SB.PCI0.LPC0.EC0.ECWT (MGOB, RefOf (\_SB.PCI0.LPC0.EC0.MGOB))
> \_SB.PCI0.LPC0.EC0.ECWT (MGOC, RefOf (\_SB.PCI0.LPC0.EC0.MGOC))
> \_SB.PCI0.LPC0.EC0.ECWT (MGOD, RefOf (\_SB.PCI0.LPC0.EC0.MGOD))
> \_SB.PCI0.LPC0.EC0.ECWT (MGOE, RefOf (\_SB.PCI0.LPC0.EC0.MGOE))
> \_SB.PCI0.LPC0.EC0.ECWT (MGOF, RefOf (\_SB.PCI0.LPC0.EC0.MGOF))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL0, RefOf (\_SB.PCI0.LPC0.EC0.CTL0))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL1, RefOf (\_SB.PCI0.LPC0.EC0.CTL1))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL2, RefOf (\_SB.PCI0.LPC0.EC0.CTL2))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL3, RefOf (\_SB.PCI0.LPC0.EC0.CTL3))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL4, RefOf (\_SB.PCI0.LPC0.EC0.CTL4))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL5, RefOf (\_SB.PCI0.LPC0.EC0.CTL5))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL6, RefOf (\_SB.PCI0.LPC0.EC0.CTL6))
> \_SB.PCI0.LPC0.EC0.ECWT (CTL7, RefOf (\_SB.PCI0.LPC0.EC0.CTL7))
> \_SB.PCI0.LPC0.EC0.ECWT (0xE0, RefOf (\_SB.PCI0.LPC0.EC0.USDC))
> IO80 = 0xD1
> }
>
> Method (ECRD, 0, Serialized)
> {
> IO80 = 0xD3
> MGI0 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI0))
> MGI1 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI1))
> MGI2 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI2))
> MGI3 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI3))
> MGI4 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI4))
> MGI5 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI5))
> MGI6 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI6))
> MGI7 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI7))
> MGI8 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI8))
> MGI9 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGI9))
> MGIA = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGIA))
> MGIB = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGIB))
> MGIC = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGIC))
> MGID = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGID))
> MGIE = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGIE))
> MGIF = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.MGIF))
> VER1 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.VER1))
> VER2 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.VER2))
> RSV1 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.RSV1))
> RSV2 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.RSV2))
> CCI0 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.CCI0))
> CCI1 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.CCI1))
> CCI2 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.CCI2))
> CCI3 = \_SB.PCI0.LPC0.EC0.ECRD (RefOf (\_SB.PCI0.LPC0.EC0.CCI3))
> \_SB.PCI0.LPC0.EC0.ECWT (0xE1, RefOf (\_SB.PCI0.LPC0.EC0.USGC))
> IO80 = 0xD4
> }
>
> Method (_DSM, 4, Serialized) // _DSM: Device-Specific
> Method
> {
> If ((Arg0 == ToUUID
> ("6f8398c2-7ca4-11e4-ad36-631042b5008f") /* Unknown UUID */))
> {
> If ((ToInteger (Arg2) == Zero))
> {
> Return (Buffer (One)
> {
> 0x0F
> // .
> })
> }
> ElseIf ((ToInteger (Arg2) == One))
> {
> ECWR ()
> }
> ElseIf ((ToInteger (Arg2) == 0x02))
> {
> ECRD ()
> }
> Else
> {
> Return (Zero)
> }
> }
>
> Return (Zero)
> }
> }
>
> Thanks,
> Rong
>
>>
>> thanks,
>>
>> greg k-h
My biggest concern with this patch is it stands a chance of growing rapidly and extensively.
We've been having a ton of UCSI issues on this years Thinkpad systems. We'll get them fixed, though it's been slow going.
I don't understand it yet (and your notes above might be useful for narrowing it down). The FW team says the FW passes all the UCSI tests under Windows, but on Linux it's really bad and I see the same on my HW.
Hopefully once we figure out what is going on with the Thinkpads the other platforms will benefit? but flagging that this error is not uncommon.
I'd be surprised if this is Lenovo only to be honest. I might be wrong, but there's really not a lot common between an Ideapad and Thinkpad - they're completely different FW teams. I would expect the chances that this shows up elsewhere to be reasonable, in which case your list will grow even more.
Can we wait until a bit more investigation has been done on Thinkpad? Right now it's on a small list of gating issues on a few of our platforms - so it is getting a bit more attention. Once we have root cause it might be easier to find a better solution?
Mark
next prev parent reply other threads:[~2026-05-11 23:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 17:59 [PATCH] usb: typec: ucsi: acpi: Disable on devices with broken firmware Rong Zhang
2026-05-11 18:25 ` Greg Kroah-Hartman
2026-05-11 19:12 ` Rong Zhang
2026-05-11 23:11 ` Mark Pearson [this message]
2026-05-12 12:46 ` Rong Zhang
2026-05-12 18:28 ` Mark Pearson
2026-05-12 19:16 ` Rong Zhang
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=06e5005d-8621-4031-b3a3-6fd735cebbd4@app.fastmail.com \
--to=mpearson-lenovo@squebb.ca \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=i@rong.moe \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--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