Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] drm/msm: 64-bit division causes build failure on 32-bit architectures --
commit a2eae50c59c6c00875971ea5d298ddc98b93dc84 Author: Mahadevan P <[email protected]> drm/msm/dpu: do not assume a merged datapath when validating mode clock This commit changes the mode clock validation logic in dpu_crtc_mode_valid() to divide by the actual number of layer mixers used, rather than always halving it when 3d_mux is present. > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c > index 0b51a4c5db577..209b25dbeb6c8 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c > @@ -1631,8 +1631,7 @@ static enum drm_mode_status dpu_crtc_mode_valid(struct > drm_crtc *crtc, > adjusted_mode_clk = dpu_core_perf_adjusted_mode_clk(mode->clock, > > dpu_kms->perf.perf_cfg); > > - if (dpu_kms->catalog->caps->has_3d_merge) > - adjusted_mode_clk /= 2; > + adjusted_mode_clk /= dpu_crtc_num_lm_for_mode(dpu_kms, mode); [Severity: Low] Does this code introduce a linker error on 32-bit architectures? The variable adjusted_mode_clk is declared as a u64, and it is being divided by the u32 result of dpu_crtc_num_lm_for_mode(). In the kernel, using the direct division operator with a non-constant on a 64-bit variable emits compiler built-in functions that are not linked on 32-bit architectures like ARM32, leading to a build failure. Could this be changed to perform the division using kernel macros like do_div() or div_u64() instead? > > /* > * The given mode, adjusted for the perf clock factor, should not exceed -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
