Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] drm/msm: Missing designated initializers in lm.base array maps LM3 to 0x0 - [High] drm/msm: Hardware register corruption from exposing LM cursor as SSPP pipe --
commit a462b33778a7f0e919c295ca897f61ab29c8108c Author: Muzaffer Kadir <[email protected]> drm: msm: mdp5: Add MDP5 configuration for MSM8952 Add the mdp5_cfg_hw entry for MDP5 version v1.12 found on MSM8952. > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c > index 7c91fc1915f39..d34c94d6f7e2e 100644 > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c [ ... ] > +static const struct mdp5_cfg_hw msm8952_config = { > + .name = "msm8952", [ ... ] > + .pipe_cursor = { > + .count = 1, > + .base = { 0x440DC }, > + .caps = MDP_PIPE_CAP_HFLIP | > + MDP_PIPE_CAP_VFLIP | > + MDP_PIPE_CAP_SW_PIX_EXT | > + MDP_PIPE_CAP_CURSOR | > + 0, > + }, [Severity: High] Does exposing the LM cursor as an SSPP pipe corrupt the LM cursor registers? When userspace performs an atomic plane update on this cursor plane, mdp5_plane_mode_set() writes standard SSPP pipe configurations to 0x440DC, which is the exact address of REG_MDP5_LM_CURSOR_STRIDE(0). Because the two hardware blocks have completely different register layouts, SSPP registers like SRC0_ADDR end up being written into LM CURSOR_XY coordinates, corrupting the layer mixer's cursor configuration. Should this cursor be handled by mdp5_crtc_cursor_set() instead of being exposed as a pipe_cursor? > + .lm = { > + .count = 2, > + .base = { 0x44000, 0x47000 }, [Severity: High] Will the base address for the LM3 (Writeback) hardware mixer evaluate to 0x0? When the driver configures the Writeback interface (LM3), it indexes mdp5_cfg->lm.base using the instance ID (mixer->lm = 3). Since the array was initialized sequentially as { 0x44000, 0x47000 }, base[1] receives 0x47000 while base[3] is zero-initialized. Writing layer mixer configuration to 0x0 corrupts the global MDP5 control registers, leading to severe hardware malfunction or system crash. Should this use designated initializers (e.g., [0] = 0x44000, [3] = 0x47000)? > + .instances = { > + { .id = 0, .pp = 0, .dspp = 0, > + .caps = MDP_LM_CAP_DISPLAY, }, > + { .id = 3, .pp = -1, .dspp = -1, > + .caps = MDP_LM_CAP_WB }, > + }, > + .nb_stages = 8, > + .max_width = 2048, > + .max_height = 0xFFFF, > + }, [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260921-msm8952-initial-support-v3-0-b96fd3fe2...@mainlining.org?part=13
