Re: ucsi_acpi: "bogus connector number in CCI: 2" flood on Acer Aspire A14-61M

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

Hi Peter,

On Tue, Oct 20, 2026 at 10:53:06PM +0100, Peter Walker wrote:
> Hello,
> 
> On an Acer Aspire A14-61M the kernel log fills with
> 
> ucsi_acpi USBC000:00: bogus connector number in CCI: 2

How many USB Type-C ports does this system have?

> at 2-4 lines a second for as long as the machine is awake, about
> 290,000 lines a day.
> 
> 
> System
> 
> Acer Aspire A14-61M (board Tiguan_SKF), AMD Ryzen AI 5 340
> BIOS INSYDE V1.29 (03/24/2026); also seen on V1.00 (04/09/2025)
> Kernel 7.2.7-ogc1.1.fc44 (Bazzite); also seen on 7.2.3 and 7.2.4
> ACPI device USBC000:00 (\_SB_.UBTC), defined in DSDT and SSDT31
> 
> 
> Where it happens
> 
> The message comes from the connector bounds check in
> ucsi_notify_common(). The laptop has two USB-C ports, but the PPM
> reports one connector, so only port0 is registered, and it then sends
> connector change notifications for connector 2.
> 
> GET_CAPABILITY (through the ucsi debugfs command file):
> 
> 0x01300300012000020000b40100000144
> bmAttributes 0x00000144, bNumConnectors 1, bmOptionalFeatures 0xb4,
> bNumAltModes 2, BC 1.2, PD 3.0, Type-C 1.3
> 
> GET_CONNECTOR_STATUS for connector 2 is answered without error. While
> the messages are being printed it returns:
> 
> 0x00000000000000010000000020004260
> change 0x4260 (PDOS, POWER_LEVEL, BC, CONNECT), not connected
> 
> As soon as that command has been issued the messages stop, and reading
> it again shows the change field cleared:
> 
> 0x00000000000000010000000020000000
> 
> 
> How to reproduce
> 
> 1. With no messages being printed, unplug the charger.
> 
> 2. About 5 seconds later the messages start. They carry on whether the
> charger is plugged back in, moved to the other port or left out.
> 
> 3. s2idle suspend pauses them; they start again 1-3 seconds after
> resume.
> 
> 4. Writing 0x20012 (GET_CONNECTOR_STATUS, connector 2) to
> /sys/kernel/debug/usb/ucsi/USBC000:00/command stops them: 17 messages
> in the 5 seconds before, none in the 5 seconds after. A suspend/resume
> cycle afterwards did not bring them back; the next charger unplug did.
> 
> 
> Other observations
> 
> - While the messages are being printed, port0 does not follow the
> charger. GET_CONNECTOR_STATUS for connector 1 reported it connected
> with a PD contract (opmode PD, sink, partner DFP, RDO 0x53851545,
> change 0x4a60), while sysfs showed port0 with no partner,
> power_operation_mode "default", and ucsi-source-psy-USBC000:001
> online=0. Three seconds after the GET_CONNECTOR_STATUS(2) in step 4,
> "UCSI_GET_PDOS failed (-70)" was logged and port0-partner, port0-cable
> and port0-plug0 appeared, with power_operation_mode
> "usb_power_delivery" and the power supply online=1.
> 
> - "UCSI_GET_PDOS failed (-70)" is also logged twice at probe on every
> boot.
> 
> - Charger plug and unplug also arrive through acer_wmi as "Unknown
> function number - 9 - 1" and "- 9 - 0".
> 
> I have the DSDT/SSDT tables, the full sysfs state and the journal, and
> I'm happy to run further tests.

Okay, can you try this:

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
index a71d070466a7b..1425b531b6f54 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -253,7 +253,6 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
        {
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
-                       DMI_MATCH(DMI_PRODUCT_NAME, "Nitro ANV15-41"),
                },
                .driver_data = (void *)&ucsi_acer_ops,
        },


Thanks,

-- 
heikki