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

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

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