Re: [PATCH v2] usb: typec: ucsi: Stop a power level change notification storm

[Mark Pearson]

On Mon, Oct 26, 2026, at 2:09 PM, David Vornholt wrote:
> Hi Heikki,
>
> On Mon, Oct 26, 2026 at 10:58:04AM +0100, Heikki Krogerus wrote:
>> On Sat, Oct 10, 2026 at 08:39:17PM +0200, David Vornholt wrote:
>> > On a Lenovo ThinkPad X1 Carbon Gen 13 (BIOS N4BET78W 1.48, EC N4BHT61W
>> > 1.41, UCSI 1.0) with an HP E273m monitor connected, the PPM keeps
>> > signaling a Negotiated Power Level Change although the power contract
>> > stays the same, and signals it again right after it has been
>> > acknowledged:
>> >
>> >   ucsi_connector_change: port1 status: change=0040, opmode=3,
>> >     connected=1, sourcing=0, partner_flags=2, partner_type=4,
>> >     request_data_obj=1304b12c, BC status=2
>>
>> Okay, so the PPM really should not report the power level changes
>> since there are not power level changes, right? Have you reported this
>> to Lenovo?
>
> Right. The connector status is the same every time, with the same RDO,
> and the Negotiated Power Level Change bit is the only one set in the
> change field.
>
> I haven't reported it to Lenovo yet, so I've added Mark to Cc. Mark,
> this is a ThinkPad X1 Carbon Gen 13 (21NT) with BIOS N4BET78W (1.48)
> and EC 1.41, which is still the latest firmware on LVFS. With an HP
> E273m connected over USB-C, the EC keeps signaling a Negotiated Power
> Level Change for an unchanged contract, about seven times a second,
> and GPE 0x6E fires about 680 times a second. Could you pass this on to
> the firmware team? The details are in the patch:
> https://lore.kernel.org/r/20261010183917.146821-1-dv@xxxxxxxx
>

I need to read through the patch properly - but the X1 Carbon is quite popular and used by lots of people. Have we been able to rule out it being the E273m on another machine?

I've created internal ticket LO-4728 so we can see if we can reproduce and get input from the FW team on why so many notifications would be generated - generated so many seems quite wrong.

>> This problem may only affect your system, so we really have to isolate
>> it somehow. I'm almost certain that like this there will be problems
>> on some other systems.
>
> OK. How about a quirk for this machine only? ucsi_acpi would match it
> by DMI (LENOVO, "ThinkPad X1 Carbon Gen 13") and set a new quirk flag,
> and ucsi_get_supported_notifications() would then leave
> UCSI_ENABLE_NTFY_PWR_LEVEL_CHANGE out of the mask. That replaces all of
> the detection logic in v2 and changes nothing on other systems.
>

I've only skim read the proposed patch, but I'm also hesitant to say this is X1 C13 specific.

As anote, if you do end doing a quirk then that field is bad as there are two different variants of the X1 Carbon 13 - ARL and LNL. Better to use DMI checks on the BOARD_NAME - there are two per platform, and I believe you're on Lunarlake so would be 21NS and 21NT.

Mark