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

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

[Carlo D'Ambrosio]

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

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

[Carlo D'Ambrosio]

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

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

[Heikki Krogerus]

On Sun, Sep 27, 2026 at 09:04:09PM +0200, Carlo D'Ambrosio wrote:
> 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?

Please report the issue to Acer if you have not yet done so. This is
an obvious FW/PPM issue.

Thanks,

-- 
heikki