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

[David Vornholt <dv@etik.com>]

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@etik.com

> 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 tested the effect of that on this machine, with a test switch that
kept the notification disabled from the start. With the monitor
connected, the PPM signaled no connector changes at all, and GPE 0x6E
dropped to about 5/s, from about 680/s with the stock driver. The cost
is that on this machine the driver won't notice a real power level
change until the PPM signals some other connector change. The EC
handles charging on its own.

> Something that I did not quite understand from the above is, if you
> revert commit a0d4618788f2, do you still have a problem (I understand
> that you still get the repeated notifications, but do they cause other
> problems then)?

Yes, though only about half as bad. I didn't test a plain revert, but
my first attempt did the same for these notifications: it skipped
ucsi_pwr_opmode_change() when the RDO hadn't changed. That's where the
"about 360 a second" in the commit message comes from. The PPM still
signaled the next change right after each ACK, so the driver read the
connector status and acknowledged it about nine times a second, back to
back. At about 50 ms of EC transactions per command, the connector work
and the EC were still busy almost all the time. Only disabling the
notification stopped that.

I didn't measure CPU time or power draw with that version. If numbers
for a plain revert would help, I can get them.

If the quirk is OK with you, I'll send a v3 with it.

Thanks,
David