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 <[email protected]> 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/[email protected]?part=1
