Re: [BUG] usb: typec: ucsi: Acer Aspire 16 AI reports connector 2 while num_connectors=1
From: Heikki Krogerus
Date: Mon Sep 28 2026 - 10:17:29 EST
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