[BUG] usb: typec: ucsi: Acer Aspire 16 AI reports connector 2 while num_connectors=1

[Carlo D'Ambrosio <carlo.dambrosio@gmail.com>]

Hello,

I am seeing a reproducible UCSI issue on an Acer Aspire 16 AI running 
Fedora 44.

System:
- Acer Aspire 16 AI
- BIOS 1.22 (latest available from Acer)
- Fedora 44
- Linux 7.2.7-200.fc44.x86_64
- Dual boot with Windows 11
- Two physical USB-C ports on the left side of the laptop; the upper one 
is Thunderbolt-capable

The problem occurs when I connect either a USB device or the original 
Acer charger to the upper USB-C/Thunderbolt port.

Immediately after connecting it, the kernel log starts being flooded with:

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

The messages continue after disconnecting the device and also survive a 
normal Fedora reboot.

The lower USB-C port does not trigger the problem.

The condition can be cleared in either of these ways:

1. Power off and perform an EC reset by holding the power button for 
about 30 seconds.
2. Boot Windows 11 and then reboot into Fedora.

Interestingly, Windows itself does not appear to trigger the problem. 
After Windows -> Fedora, Fedora starts cleanly again until something is 
connected to the affected upper USB-C port.

Reloading ucsi_acpi does not clear the underlying condition:

   modprobe -r ucsi_acpi
   modprobe ucsi_acpi

Removing the module stops the log messages, but after loading it again 
the flooding resumes.

In a clean Fedora boot (after Windows -> Fedora, with nothing connected) 
I get:

   typec port0: bound usb3-port1 (ops connector_ops)
   typec port0: bound usb2-port1 (ops connector_ops)
   typec port0: bound usb4_port1 (ops connector_ops [thunderbolt])
   ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-70)
   ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-70)

There is no "bogus connector number" flooding at this point.

Also, /sys/class/typec contains only port0.

I used bpftrace to inspect the UCSI state directly.

While the failure is active, tracing ucsi_acpi_read_cci() shows:

   ret=0  CCI=0x20000004

repeatedly.

I also traced ucsi_notify_common() while reading the UCSI capability 
stored by the kernel:

   CCI=0x20000004  num_connectors=1

This repeats continuously.

I then reproduced the issue starting from a known-clean Fedora boot. 
Before connecting anything there were no such notifications. I started 
the ucsi_notify_common() probe and connected the original Acer charger 
to the affected upper USB-C port.

The very first notification observed was already:

   CCI=0x20000004  num_connectors=1

and it then repeated continuously.

The bpftrace probe used was:

   kfunc:ucsi_notify_common
   {
       printf("CCI=0x%08x  num_connectors=%u\n",
              args.cci,
              args.ucsi->cap.num_connectors);
   }

I separately traced ucsi_acpi_read_cci() with:

   kfunc:ucsi_acpi_read_cci
   {
       @cci[tid] = args.cci;
   }

   kretfunc:ucsi_acpi_read_cci
   /@cci[tid]/
   {
       $p = @cci[tid];

       printf("ret=%d  CCI=0x%08x\n",
              retval,
              *(uint32 *)$p);

       delete(@cci[tid]);
   }

This indicates that 0x20000004 is already being returned through the 
ACPI UCSI path; it is not a connector number subsequently generated by 
the typec_ucsi bounds check.

I also verified:

   ucsi->cap.num_connectors = 1

using BTF/bpftrace.

Finally, I inspected the Fedora typec_ucsi module corresponding to the 
running 7.2.7 kernel. In ucsi_init(), the code calls ucsi_reset_ppm() 
and subsequently obtains the capability data into ucsi->cap. The 
num_connectors field being used by the core is therefore 1 when the 
connector-2 CCI notifications are received.

So the state visible to Linux appears to be:

   UCSI capability:
       num_connectors = 1

   after using upper USB-C port:
       CCI = 0x20000004
       connector change = 2

which results in:

   bogus connector number in CCI: 2

I am aware of the earlier UCSI issue where connector notifications could 
arrive before num_connectors had been initialized, resulting in 
num_connectors == 0. This does not appear to be the same case: 
num_connectors is already initialized to 1 here, and the problem can be 
triggered reproducibly after the system is fully booted.

The fact that booting Windows clears the persistent condition is also 
interesting, although I do not know what initialization/reset sequence 
Windows performs and I do not want to infer the root cause from that alone.

Could you advise whether this looks like an Acer UCSI/PPM firmware 
inconsistency, or whether something in the Linux UCSI/ACPI 
initialization could cause the second physical USB-C port to generate 
connector-2 notifications while GET_CAPABILITY exposes only one connector?

I can provide additional bpftrace output, ACPI tables, full dmesg, or 
run additional tests if useful.

Regards,


Carlo D'Ambrosio