linux-kernel - Re: [PATCH 09/10] pmdomain: renesas: rcar-gen4-sysc: Use scoped device node handling to simplify error paths

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdUQ5AD1QoO5F1nAy+GJoGtbi2ztKfK=2buU1MNeO8etJw@mail.gmail.com>
Date: Tue, 27 Aug 2024 12:55:40 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Ulf Hansson <ulf.hansson@...aro.org>, Heiko Stuebner <heiko@...ech.de>, 
	Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, 
	Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Magnus Damm <magnus.damm@...il.com>, 
	linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	imx@...ts.linux.dev, linux-arm-msm@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH 09/10] pmdomain: renesas: rcar-gen4-sysc: Use scoped
 device node handling to simplify error paths

Hi Krzysztof,

On Tue, Aug 27, 2024 at 11:39 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
> On 27/08/2024 11:33, Krzysztof Kozlowski wrote:
> > On 27/08/2024 09:48, Geert Uytterhoeven wrote:
> >> On Fri, Aug 23, 2024 at 2:51 PM Krzysztof Kozlowski
> >> <krzysztof.kozlowski@...aro.org> wrote:
> >>> Obtain the device node reference with scoped/cleanup.h to reduce error
> >>> handling and make the code a bit simpler.
> >>>
> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> >>
> >> Thanks for your patch!
> >>
> >>> --- a/drivers/pmdomain/renesas/rcar-gen4-sysc.c
> >>> +++ b/drivers/pmdomain/renesas/rcar-gen4-sysc.c
> >>> @@ -303,12 +304,12 @@ static int __init rcar_gen4_sysc_pd_init(void)
> >>>         const struct rcar_gen4_sysc_info *info;
> >>>         const struct of_device_id *match;
> >>>         struct rcar_gen4_pm_domains *domains;
> >>> -       struct device_node *np;
> >>>         void __iomem *base;
> >>>         unsigned int i;
> >>>         int error;
> >>>
> >>> -       np = of_find_matching_node_and_match(NULL, rcar_gen4_sysc_matches, &match);
> >>> +       struct device_node *np __free(device_node) =
> >>> +               of_find_matching_node_and_match(NULL, rcar_gen4_sysc_matches, &match);
> >>
> >> This breaks the declarations/blank-line/code structure, so please move
> >> this up.
> >
> > What do you mean "declaration structure"? That's the way how variables

First a block with declarations, then a blank line, followed by the actual code
(yeah, the pre-C99 style ;-)

> > with constructors are expected to be declared - within the code.

When it matters.

> Continuing thoughts, so you prefer:
>
>         struct rcar_gen4_pm_domains *domains;
>         void __iomem *base;
>         struct device_node *np __free(device_node) =
>                 of_find_matching_node_and_match(NULL, rcar_gen4_sysc_matches, &match);
>
> (assuming I will put it at the end of declarations).
>
> Are you sure this is more readable? It's really long line so it
> obfuscates a bit the declarations. The point of the scoped assignment is that
> you declare it at point of need/first use.

You're missing reverse Christmas tree order...

> >> If you insist on keeping assignment to and validation of np together,
> >> the line should be split in declaration and assignment.
> >
> > No, that would be inconsistent with cleanup/constructor coding style.
> > Maybe this is something new, so let me bring previous discussions:

[...]

> > and finally it will reach documentation (although it focuses on

Oh, "finally" as in not yet upstream ;-)

> > unwinding process to be specific - "When the unwind order ..."):
> > https://lore.kernel.org/all/171175585714.2192972.12661675876300167762.stgit@dwillia2-xfh.jf.intel.com/

"When the unwind order matters..."

So it's perfectly fine to have:

    static int __init rcar_gen4_sysc_pd_init(void)
    {
            struct device_node *np __free(device_node) = NULL;
            struct rcar_gen4_pm_domains *domains;
            const struct rcar_gen4_sysc_info *info;
            const struct of_device_id *match;
            void __iomem *base;
            unsigned int i;
            int error;

            np = of_find_matching_node_and_match(NULL,
rcar_gen4_sysc_matches, &match);
            if (!np)
                    return -ENODEV;

            ...
    }

But my first suggestion:

    static int __init rcar_gen4_sysc_pd_init(void)
    {
            struct device_node *np __free(device_node) =
                    of_find_matching_node_and_match(NULL,
rcar_gen4_sysc_matches, &match);
            struct rcar_gen4_pm_domains *domains;
            const struct rcar_gen4_sysc_info *info;
            const struct of_device_id *match;
            void __iomem *base;
            unsigned int i;
            int error;

            if (!np)
                    return -ENODEV;

            ...
    }

is safer w.r.t. to future modification.

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