linux-kernel - Re: [PATCH] drm/rcar-du: fix comment to rcar_du_group

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]

Date:   Mon, 4 Sep 2023 08:56:48 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Alexandra Diupina <adiupina@...ralinux.ru>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>,
        Biju Das <biju.das.jz@...renesas.com>,
        dri-devel@...ts.freedesktop.org, linux-renesas-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org, lvc-project@...uxtesting.org
Subject: Re: [PATCH] drm/rcar-du: fix comment to rcar_du_group_get()

Hi Alexandra,

On Sun, Sep 3, 2023 at 7:10 PM Alexandra Diupina <adiupina@...ralinux.ru> wrote:
> rcar_du_group_get() never returns a negative
> error code (always returns 0), so change
> the comment about returned value
>
> Fixes: cb2025d2509f ("drm/rcar-du: Introduce CRTCs groups")
> Signed-off-by: Alexandra Diupina <adiupina@...ralinux.ru>

Thanks for your patch!

> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> @@ -200,7 +200,7 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
>   *
>   * This function must be called with the DRM mode_config lock held.
>   *
> - * Return 0 in case of success or a negative error code otherwise.
> + * Always return 0.
>   */
>  int rcar_du_group_get(struct rcar_du_group *rgrp)
>  {

This is debatable: future changes may make it possible for the
function to fail.  In addition, the (single) caller does check the
return value.

If we are sure the function can never fail, and everyone agrees, its
return type should be changed to void, and the caller should be updated.

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