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

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

Hello,

I did one additional A/B trace which seems to explain why the 
notification storm persists.

Starting from a clean Windows -> Fedora boot, I traced 
|ucsi_notify_common()|and |ucsi_acpi_async_control()|and connected the 
charger to the lower USB-C port, which behaves normally.

The first event was:

|NOTIFY CCI=0x20000002 connector=1 num_connectors=1 CONTROL 
command=0x0000000000010012|

|0x12|is |UCSI_GET_CONNECTOR_STATUS|, with connector 1 encoded in the 
command.

This was followed by:

|NOTIFY CCI=0x80000900 CONTROL command=0x0000000000030004 NOTIFY 
CCI=0x20000000|

 From |ucsi.h|, |0x04|is |UCSI_ACK_CC_CI|, bit 16 is 
|UCSI_ACK_CONNECTOR_CHANGE|, and bit 17 is |UCSI_ACK_COMMAND_COMPLETE|. 
Therefore |0x00030004|is:

|ACK_CC_CI | ACK_CONNECTOR_CHANGE | ACK_COMMAND_COMPLETE|

So for the valid connector-1 notification, Linux performs the expected 
|GET_CONNECTOR_STATUS(1)|and subsequently acknowledges the connector change.

In contrast, when the upper USB-C port triggers the problem, the trace 
is only:

|NOTIFY CCI=0x20000004 connector=2 num_connectors=1 NOTIFY 
CCI=0x20000004 connector=2 num_connectors=1 ...|

approximately every 570 ms, with *no calls at all to 
|ucsi_acpi_async_control()|*during the loop.

This matches |ucsi_notify_common()|: because connector 2 is greater than 
|ucsi->cap.num_connectors|(1), |ucsi_connector_change()|is not called, 
so the normal connector-change handling/acknowledgement path is never 
entered.

Also, to correct an interpretation I was considering earlier: 
|0x20000004|is *ACK_COMPLETE + connector 2*, not ERROR + connector 2 
(|UCSI_CCI_ACK_COMPLETE|is bit 29; |UCSI_CCI_ERROR|is bit 30).

This seems to leave two separate questions:

 1. Why does the PPM expose |num_connectors=1|via GET_CAPABILITY while
    the upper physical USB-C port generates connector-change indicator 2?
 2. Independently, should Linux do anything to acknowledge/drop an
    out-of-range connector-change notification to prevent a persistent
    notification storm, or is the current behavior intentional?

I can run further traces/tests if useful.

Thank you.

Regards,


Carlo D'Ambrosio


Il 27/09/26 18:34, Carlo D'Ambrosio ha scritto:
> 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