Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/vc4: CEC register corruption via HSM clock divider overflow --
commit ea5ddad9978e31ee47e604996aa2db29025b7ffb Author: Cristian Ciocaltea <[email protected]> drm/vc4: hdmi: Bump BCM2835 max pixel clock to 165 MHz This commit increases the maximum pixel clock for BCM2835 HDMI from 162 MHz to 165 MHz. It allows users to use pixel clocks closer to the HSM clock, which is now scaled to 101% of the pixel clock rate. > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > index 8e4623ccc4f8d..e61f1b694dbe2 100644 > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c [ ... ] > @@ -3363,7 +3363,7 @@ static const struct vc4_hdmi_variant bcm2835_variant = { > .encoder_type = VC4_ENCODER_TYPE_HDMI0, > .debugfs_name = "hdmi_regs", > .card_name = "vc4-hdmi", > - .max_pixel_clock = 162000000, > + .max_pixel_clock = HDMI_1_0_TMDS_CHAR_RATE_MAX_HZ, [Severity: High] Does increasing the max pixel clock to 165 MHz cause an unmasked integer overflow that corrupts the CEC register? When modesetting at 165 MHz, the HSM clock is scaled to 166.65 MHz (101%). This execution flows through vc4_hdmi_encoder_pre_crtc_configure() down to vc4_hdmi_cec_update_clk_div(): drivers/gpu/drm/vc4/vc4_hdmi.c:vc4_hdmi_cec_update_clk_div(): clk_cnt = cec_rate / CEC_CLOCK_FREQ; value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT; HDMI_WRITE(HDMI_CEC_CNTRL_1, value); The CEC clock divider calculation (166.65 MHz / 40 kHz) yields 4166 (0x1046), which exceeds the 12-bit VC4_HDMI_CEC_DIV_CLK_CNT limit (4095). Since the value is unmasked, it spills directly into the adjacent VC4_HDMI_CEC_ADDR_MASK field, silently breaking CEC functionality on 165 MHz modesets. > .registers = vc4_hdmi_fields, > .num_registers = ARRAY_SIZE(vc4_hdmi_fields), -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
