linux-kernel - Re: [PATCH] drm/rcar-du: dsi: Clean up VCLK divider calculation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdUxOa2zUP8d7F=dUPP+Lun=_KHeU2N-OqxxknGnn24X0A@mail.gmail.com>
Date: Mon, 5 Jan 2026 17:38:40 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Marek Vasut <marek.vasut+renesas@...lbox.org>
Cc: dri-devel@...ts.freedesktop.org, kernel test robot <lkp@...el.com>, 
	David Airlie <airlied@...il.com>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Kieran Bingham <kieran.bingham+renesas@...asonboard.com>, 
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Magnus Damm <magnus.damm@...il.com>, 
	Maxime Ripard <mripard@...nel.org>, Simona Vetter <simona@...ll.ch>, 
	Thomas Zimmermann <tzimmermann@...e.de>, 
	Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>, linux-kernel@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH] drm/rcar-du: dsi: Clean up VCLK divider calculation

Hi Marek,

On Wed, 31 Dec 2025 at 15:57, Marek Vasut
<marek.vasut+renesas@...lbox.org> wrote:
> Currently, in rcar_mipi_dsi_parameters_calc(), the VCLK divider is stored
> in setup_info structure as BIT(divider). The rcar_mipi_dsi_parameters_calc()
> is called at the early beginning of rcar_mipi_dsi_startup() function. Later,
> in the same rcar_mipi_dsi_startup() function, the stored BIT(divider) value
> is passed to __ffs() to calculate back the divider out of the value again.
>
> Factor out VCLK divider calculation into rcar_mipi_dsi_vclk_divider()
> function and call the function from both rcar_mipi_dsi_parameters_calc()
> and rcar_mipi_dsi_startup() to avoid this back and forth BIT() and _ffs()
> and avoid unnecessarily storing the divider value in setup_info at all.
>
> This rework has a slight side-effect, in that it should allow the compiler
> to better evaluate the code and avoid compiler warnings about variable
> value overflows, which can never happen.
>
> Reported-by: kernel test robot <lkp@...el.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202512051834.bESvhDiG-lkp@intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202512222321.TeY4VbvK-lkp@intel.com/
> Signed-off-by: Marek Vasut <marek.vasut+renesas@...lbox.org>

Thanks for your patch!

> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> @@ -412,18 +427,20 @@ static void rcar_mipi_dsi_parameters_calc(struct rcar_mipi_dsi *dsi,
>
>         fin_rate = clk_get_rate(clk);
>
> +       div = rcar_mipi_dsi_vclk_divider(dsi, setup_info);
> +
>         switch (dsi->info->model) {
>         case RCAR_DSI_V3U:
>         default:
> -               setup_info->vclk_divider = 1 << ((clk_cfg->vco_cntrl >> 4) & 0x3);
> +               vclk_divider = BIT_U32(div);

BIT_U16(), as vclk_divider is u16?

>                 break;
>
>         case RCAR_DSI_V4H:
> -               setup_info->vclk_divider = 1 << (((clk_cfg->vco_cntrl >> 3) & 0x7) + 1);
> +               vclk_divider = BIT_U32(div + 1);

Likewise.

>                 break;
>         }
>
> -       rcar_mipi_dsi_pll_calc(dsi, fin_rate, fout_target, setup_info);
> +       rcar_mipi_dsi_pll_calc(dsi, fin_rate, fout_target, setup_info, vclk_divider);
>
>         /* Find hsfreqrange */
>         setup_info->hsfreq = setup_info->fout * 2;

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds