[PATCH] usb: typec: displayport: defer instead of failing when the port is not DFP

[PATCH] usb: typec: displayport: defer instead of failing when the port is not DFP

[Jean-Francois Bobier]

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.

Signed-off-by: Jean-Francois Bobier <jean-francois.bobier@laposte.net>
---
 drivers/usb/typec/altmodes/displayport.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
index 51c92dd88..d84785309 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -766,9 +766,19 @@ 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. */
+	/*
+	 * 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)
-		return -EPROTO;
+		return -EPROBE_DEFER;
 
 	/* Make sure we have compatible pin configurations */
 	if (!(DP_CAP_PIN_ASSIGN_DFP_D(port->vdo) &
-- 
2.55.0

[PATCH v2] usb: typec: displayport: defer instead of failing when the port is not DFP

[Jean-Francois Bobier]

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

Re: [PATCH v2] usb: typec: displayport: defer instead of failing when the port is not DFP

[Heikki Krogerus]

On Mon, Oct 05, 2026 at 03:20:31PM +0200, Jean-Francois Bobier wrote:
> 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>

Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

> ---
> 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

-- 
heikki