Re: [PATCH] drm/i915/hdcp: Fail fast when HDCP Type 1 is unsupported via MST

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/i915: stale cached HDCP capability causes spurious atomic check failures
--

commit 74bd0c52833336220c44be4fec288971d8f48f92
Author: George D. Sworo <george.d.sworo@intel.com>

drm/i915/hdcp: Fail fast when HDCP Type 1 is unsupported via MST

This commit queries the downstream sink through its MST remote AUX channel
during HDCP initialization to cache whether HDCP Type 1 is unsupported. It
then uses this cached value in intel_hdcp_atomic_check() to reject invalid
HDCP Type 1 requests early.

> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index e56df337dc6d8..7490fc0fd96ab 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
[ ... ]
> @@ -2421,6 +2441,10 @@ int intel_hdcp_init(struct intel_connector *connector,
>  	if (is_hdcp2_supported(display))
>  		intel_hdcp2_init(connector, dig_port, shim);
>  
> +	/* Cache the remote capability before atomic checks can run. */
> +	connector->mst.type1_unsupported =
> +		intel_hdcp_mst_type1_is_unsupported(connector, shim);

[Severity: Medium]
Does caching this capability during intel_hdcp_init() fail to account for
subsequent monitor hotplugs? If an MST dock is connected with an HDCP 1.x
monitor (or no monitor) initially, connector->mst.type1_unsupported evaluates
to true. If an HDCP 2.x monitor is later hotplugged into the same port, the
stale cached value will remain.

>  	ret = drm_connector_attach_content_protection_property(&connector->base,
>  							       hdcp->hdcp2_supported);
[ ... ]
> @@ -2700,7 +2725,20 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
>  		if (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
>  			new_state->content_protection =
>  				DRM_MODE_CONTENT_PROTECTION_DESIRED;
> -		return;
> +		return 0;
> +	}
> +
> +	/*
> +	 * Fail fast if userspace asks for Type1 but neither the platform nor
> +	 * the downstream sink can do HDCP 2.x, instead of only discovering
> +	 * this once intel_hdcp_enable() is reached.
> +	 */
> +	if (new_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> +	    new_state->hdcp_content_type == DRM_MODE_HDCP_CONTENT_TYPE1 &&
> +	    intel_connector->mst.type1_unsupported) {
> +		drm_dbg_kms(connector->dev,
> +			    "HDCP Type1 requested without HDCP 2.x support\n");
> +		return -EOPNOTSUPP;
>  	}

[Severity: Medium]
Could this lead to spurious rejections of valid HDCP Type 1 requests for
hotplugged monitors? When userspace requests HDCP Type 1 for a newly connected
HDCP 2.x monitor, the atomic check reads the stale cached flag and spuriously
fails the request with -EOPNOTSUPP, preventing the display of premium content.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925035639.2034315-1-george.d.sworo@intel.com?part=1