From: Jean-Francois Bobier <jean-francois.bobier@laposte.net>
To: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH v2] usb: typec: displayport: defer instead of failing when the port is not DFP
Date: Mon, 5 Oct 2026 15:20:31 +0200 [thread overview]
Message-ID: <e416c2c7-4a10-4061-bbb9-cb1aa5958798@laposte.net> (raw)
In-Reply-To: <20261005125645.17899-1-jean-francois.bobier@laposte.net>
dp_altmode_probe() rejects a port that is not yet TYPEC_HOST with
-EPROTO. That is a permanent failure: the altmode device stays bound to
nothing and the driver core never retries it.
The role is not stable at that point. With a dock, the partner's
alternate modes are registered while the port is still UFP and the
data-role swap happens afterwards, so whether DisplayPort comes up at
all depends on the altmode happening to be registered a second time
after the swap. On the OnePlus 8T this made DP-over-USB-C work on some
attaches and not others, with "dp_altmode: probe ... failed with error
-71" as the only clue.
Return -EPROBE_DEFER so the core retries once the role settles, and
release the plug altmode reference obtained earlier in the function
before doing so -- the very next check in this same function already
follows that convention on its own early-return path. The leak existed
on the original -EPROTO path too, but turning a one-shot terminal
failure into a retried EPROBE_DEFER means it would otherwise repeat on
every deferred probe attempt instead of happening once.
Signed-off-by: Jean-Francois Bobier <jean-francois.bobier@laposte.net>
---
Changes in v2:
- Release the plug altmode reference before the new -EPROBE_DEFER
return, matching the convention the next check in the same function
already follows. Not present in v1; found while re-checking usb-next
for related in-flight work after v1 was sent, which turned up a
since-stalled June 2026 patch proposing the same cleanup on the
original -EPROTO path (https://ratatoskr.run/lkml/2026/06/17182803/t).
That patch hasn't landed, so this isn't a duplicate, but credit for
spotting the leak belongs there, not here.
drivers/usb/typec/altmodes/displayport.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index 51c92dd88..91d72789e 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -766,9 +766,21 @@ int dp_altmode_probe(struct typec_altmode *alt)
struct dp_altmode *dp;
u32 cap = DP_CAP_CAPABILITY(alt->vdo);
- /* Port can only be DFP_U. */
- if (typec_altmode_get_data_role(alt) != TYPEC_HOST)
- return -EPROTO;
+ /*
+ * Port can only be DFP_U.
+ *
+ * Defer rather than reject: on a dock the partner registers its
+ * altmodes while the port is still UFP, so a hard -EPROTO here drops
+ * the DisplayPort altmode permanently and nothing retries it --
+ * binding then depends on the altmode happening to be re-registered
+ * after the data-role swap. -EPROBE_DEFER makes the driver core retry
+ * once the role settles, which is deterministic and stops logging a
+ * failure for an ordinary ordering race.
+ */
+ if (typec_altmode_get_data_role(alt) != TYPEC_HOST) {
+ typec_altmode_put_plug(plug);
+ return -EPROBE_DEFER;
+ }
/* Make sure we have compatible pin configurations */
if (!(DP_CAP_PIN_ASSIGN_DFP_D(port->vdo) &
--
2.55.0
next prev parent reply other threads:[~2026-10-05 13:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 12:56 [PATCH] usb: typec: displayport: defer instead of failing when the port is not DFP Jean-Francois Bobier
2026-10-05 13:20 ` Jean-Francois Bobier [this message]
2026-10-09 11:39 ` [PATCH v2] " Heikki Krogerus
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=e416c2c7-4a10-4061-bbb9-cb1aa5958798@laposte.net \
--to=jean-francois.bobier@laposte.net \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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