Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The fallback TMDS character rate validation is silently bypassed for HDMI bridge connectors because the bridge framework unconditionally provides a wrapper callback. --
commit 98644f49de11eb659578421bd532a4a887719f94 Author: Cristian Ciocaltea <[email protected]> drm/display: hdmi-state-helper: Add fallback TMDS rate validation Validate the computed TMDS character rate against connector limits when no driver-specific hook is provided. > diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c > b/drivers/gpu/drm/display/drm_hdmi_state_helper.c > index ce17eeefc2da4..db76699093e87 100644 > --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c > +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c > @@ -566,6 +566,9 @@ hdmi_clock_valid(const struct drm_connector *connector, > status = funcs->tmds_char_rate_valid(connector, mode, clock); > if (status != MODE_OK) > return status; > + } else if (connector->hdmi.max_tmds_char_rate) { [Severity: Medium] Does this else if structure bypass the fallback logic for HDMI bridge connectors? The bridge framework always provides a wrapper for its connectors: drm_bridge_connector_tmds_char_rate_valid() { if (bridge->funcs->hdmi_tmds_char_rate_valid) return bridge->funcs->hdmi_tmds_char_rate_valid(...); else return MODE_OK; } Because this wrapper unconditionally exists, funcs->tmds_char_rate_valid evaluates to true in hdmi_clock_valid(). If the underlying bridge lacks its own validation, the wrapper simply returns MODE_OK. Since this was checked in the first if statement, the execution skips the else if branch entirely. Will this prevent the max_tmds_char_rate limit from being enforced on bridge drivers, potentially allowing unsupported display modes to be selected? > + if (clock > connector->hdmi.max_tmds_char_rate) > + return MODE_CLOCK_HIGH; > } > > return MODE_OK; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=9
