Linux USB
 help / color / mirror / Atom feed
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

  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