From: Alexey Charkov <alchark@flipper.net>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexey Charkov <alchark@flipper.net>
Subject: [PATCH] usb: typec: fusb302: Drop unacknowledged Get_Source_Cap_Extended
Date: Mon, 02 Nov 2026 17:09:05 +0400 [thread overview]
Message-ID: <20261102-fusb302-getsourcecap-v1-1-26b5bfea4b2b@flipper.net> (raw)
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@flipper.net>
---
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@flipper.net>
reply other threads:[~2026-11-02 13:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261102-fusb302-getsourcecap-v1-1-26b5bfea4b2b@flipper.net \
--to=alchark@flipper.net \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®