Re: [PATCH] usb: typec: fusb302: Drop unacknowledged Get_Source_Cap_Extended
From: Heikki Krogerus
Date: Fri Nov 06 2026 - 07:39:31 EST
On Mon, Nov 02, 2026 at 05:09:05PM +0400, Alexey Charkov wrote:
> The chip mistakes Get_Source_Cap_Extended for a GoodCRC, as it apparently
> decodes only the low four bits of the message type. As a result, it sends
> no GoodCRC for it, but still queues it in the RX FIFO. The partner never
> sees the message as delivered due to no GoodCRC, so it retries and then
> sends a Soft_Reset. When FUSB302 receives the Soft_Reset, it finally
> raises its interrupt, at which point TCPM sees Get_Source_Cap_Extended in
> the RX FIFO instead of the Soft_Reset it just received, and answers it
> Not_Supported, which is not a valid reply to Soft_Reset, so the partner
> escalates to a hard reset instead of getting a chance to gracefully handle
> a lost Get_Source_Cap_Extended.
>
> Discard Get_Source_Cap_Extended, which FUSB302 can never properly receive
> due to its inability to automatically GoodCRC it, and answering it from
> the host within the protocol specified 250us window without so much as an
> interrupt cannot be made to work.
>
> This way the TCPM view of the PD exchange at least matches what the
> partner saw on the wire. This lets the TCPM complete a PD negotiation over
> the FUSB302 with e.g. an Apple Studio Display, which otherwise always ends
> in hard resets.
>
> Signed-off-by: Alexey Charkov <alchark@xxxxxxxxxxx>
Acked-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
> ---
> drivers/usb/typec/tcpm/fusb302.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c
> index 3319f6a2b0c9..96dc48250d6a 100644
> --- a/drivers/usb/typec/tcpm/fusb302.c
> +++ b/drivers/usb/typec/tcpm/fusb302.c
> @@ -1463,6 +1463,19 @@ static int fusb302_pd_read_message(struct fusb302_chip *chip,
> fusb302_log(chip, "PD message header: %x", msg->header);
> fusb302_log(chip, "PD message len: %d", len);
>
> + /*
> + * The chip only decodes the low four bits of the message type, so it
> + * mistakes Get_Source_Cap_Extended (17) for a GoodCRC (1): it neither
> + * acknowledges it nor raises GCRCSENT, yet still queues it in the RX
> + * FIFO. Without a GoodCRC the partner never considers it delivered and
> + * will retry and then soft reset, so it must not be answered.
> + */
> + if ((!len) &&
> + (pd_header_type_le(msg->header) == PD_CTRL_GET_SOURCE_CAP_EXT)) {
> + fusb302_log(chip, "dropping unacknowledged PD message");
> + return ret;
> + }
> +
> /*
> * Check if we've read off a GoodCRC message. If so then indicate to
> * TCPM that the previous transmission has completed. Otherwise we pass
>
> ---
> base-commit: 7649ba73f9e7e1e04d0b46213e39c79ae09dd55c
> change-id: 20261102-fusb302-getsourcecap-01c38dccb230
>
> Best regards,
> --
> Alexey Charkov <alchark@xxxxxxxxxxx>
--
heikki