Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] mode_valid and atomic_get_input_bus_fmts validate display modes against an unbounded, stale, or uninitialized link rate, bypassing Device Tree limits and DPCD capabilities. -- commit 4683d3daece6ab3ba3c7c82ebff7364e878794fb Author: AngeloGioacchino Del Regno <[email protected]> Date: Wed Jul 1 12:20:21 2026 +0000 drm/mediatek: mtk_dp: Move max link rate to SoC specific data This patch moves the maximum link rate to the SoC specific data structure instead of statically assigning it to DP_LINK_BW_5_4 during initialization. This prepares the driver for the MT8196 SoC which supports higher link rates. > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c > b/drivers/gpu/drm/mediatek/mtk_dp.c > index bf3a4b15f3ec0..5272e717bfda0 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dp.c > +++ b/drivers/gpu/drm/mediatek/mtk_dp.c [ ... ] > @@ -1481,7 +1482,7 @@ static void mtk_dp_initialize_priv_data(struct mtk_dp > *mtk_dp) > { > bool plugged_in = (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP); > > - mtk_dp->train_info.link_rate = DP_LINK_BW_5_4; > + mtk_dp->train_info.link_rate = mtk_dp->data->hw_max_link_rate; [Severity: High] This isn't a bug introduced by this patch, but does setting the link rate here cause mode validation to falsely accept unsupported high-bandwidth modes? Looking at mtk_dp_bridge_mode_valid() in drivers/gpu/drm/mediatek/mtk_dp.c, it calculates available bandwidth using the unnegotiated train_info.link_rate: u32 rate = drm_dp_bw_code_to_link_rate(mtk_dp->train_info.link_rate) * lane_count_min; A similar calculation occurs in mtk_dp_bridge_atomic_get_input_bus_fmts(). Since train_info.link_rate is initialized here to the SoC's absolute maximum (and previously statically to DP_LINK_BW_5_4), it bypasses the board-specific Device Tree constraint mtk_dp->max_linkrate and the sink capabilities in rx_cap. When the mode is actually committed, mtk_dp_training() properly limits the link rate to mtk_dp->max_linkrate and trains at a lower bandwidth. Won't this leave the hardware unable to sustain the falsely validated high-bandwidth display mode, resulting in a blank screen or corrupted output due to bandwidth exhaustion? Because this patch will introduce even higher initial values for future SoCs like MT8196, will this cause a wider range of unsupported modes to be falsely validated? > mtk_dp->train_info.lane_count = mtk_dp->max_lanes; > mtk_dp->train_info.cable_plugged_in = plugged_in; > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8
