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

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

[Peter Walker]

Hello,

On an Acer Aspire A14-61M the kernel log fills with

ucsi_acpi USBC000:00: bogus connector number in CCI: 2

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.

Thanks,
Peter

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

[Heikki Krogerus]

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

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

[Heikki Krogerus]

On Wed, Nov 04, 2026 at 11:28:12AM +0100, Peter Walker wrote:
> I don't have the laptop with me at the moment, I can run the command you
> provided this weekend if that helps?

It would help.

Please try to avoid top-posting on the mailing list.

Thanks,

-- 
heikki

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

[Peter Walker]

On Fri, Nov 06, 2026 at 06:50:36PM +0100, Heikki Krogerus wrote:
> On Wed, Nov 04, 2026 at 11:28:12AM +0100, Peter Walker wrote:
> > I don't have the laptop with me at the moment, I can run the command you
> > provided this weekend if that helps?
>
> It would help.
>
> Please try to avoid top-posting on the mailing list.

Sorry about that. The laptop has two USB-C ports.

I tested your patch on 7.2.11-ogc4.1.fc44 (Bazzite): ucsi_acpi.c
from stable v7.2.11 with the Nitro ANV15-41 line removed, built out
of tree against the running kernel and loaded in place of the stock
module. It makes no difference here.

- "UCSI version is zero, assuming 1.2" is never logged.

- At probe, "UCSI_GET_PDOS failed (-70)" is logged twice, as on
every boot.

- The first "bogus connector number in CCI: 2" came 4.7 s after the
first of those, and acer_wmi logged a charger unplug 0.3 s later.
The stock module had been printing them until I unloaded it, about
100 s before.

- From then on they kept coming at 17 every 10 s, the same rate as
the stock module just before, while the charger went back in, out
and in again, and across an s2idle cycle. Four were logged during
the suspend and resume, and the next came 2.4 s after
"PM: suspend exit".

- port0 never followed the charger: no partner, power_operation_mode
"default" and ucsi-source-psy-USBC000:001 online=0, whether the
charger was plugged in or not.

One correction to my first report: a charger unplug may not be the only
trigger. Going back through the journal, on 8 of the 20 boots on
7.2.x kernels the messages started 3.9-4.6 s after the probe's first
"UCSI_GET_PDOS failed (-70)", before any charger event was logged.

Thanks,
Peter

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

[Heikki Krogerus]

On Fri, Nov 06, 2026 at 09:25:26PM +0000, Peter Walker wrote:
> On Fri, Nov 06, 2026 at 06:50:36PM +0100, Heikki Krogerus wrote:
> > On Wed, Nov 04, 2026 at 11:28:12AM +0100, Peter Walker wrote:
> > > I don't have the laptop with me at the moment, I can run the command you
> > > provided this weekend if that helps?
> >
> > It would help.
> >
> > Please try to avoid top-posting on the mailing list.
> 
> Sorry about that. The laptop has two USB-C ports.
> 
> I tested your patch on 7.2.11-ogc4.1.fc44 (Bazzite): ucsi_acpi.c
> from stable v7.2.11 with the Nitro ANV15-41 line removed, built out
> of tree against the running kernel and loaded in place of the stock
> module. It makes no difference here.
> 
> - "UCSI version is zero, assuming 1.2" is never logged.

Okay, but it would not help in any case. The first problem is that the
PPM reports the wrong number of connector, right?

That is a pretty obvious FW bug. Did you report that to Acer?

We can prepare a quirk where that is fixed, but it means that the FW
may never get fixed. So let's try to get the FW fixed first.

> - At probe, "UCSI_GET_PDOS failed (-70)" is logged twice, as on
> every boot.

This is probable another issue. Let's tackle these one by one.

> - The first "bogus connector number in CCI: 2" came 4.7 s after the
> first of those, and acer_wmi logged a charger unplug 0.3 s later.
> The stock module had been printing them until I unloaded it, about
> 100 s before.
> 
> - From then on they kept coming at 17 every 10 s, the same rate as
> the stock module just before, while the charger went back in, out
> and in again, and across an s2idle cycle. Four were logged during
> the suspend and resume, and the next came 2.4 s after
> "PM: suspend exit".

Can you share the complete dmesg output?

> - port0 never followed the charger: no partner, power_operation_mode
> "default" and ucsi-source-psy-USBC000:001 online=0, whether the
> charger was plugged in or not.
> 
> One correction to my first report: a charger unplug may not be the only
> trigger. Going back through the journal, on 8 of the 20 boots on
> 7.2.x kernels the messages started 3.9-4.6 s after the probe's first
> "UCSI_GET_PDOS failed (-70)", before any charger event was logged.

Thanks,

-- 
heikki