[PATCH 2/4] cpuidle: riscv-sbi: Use scoped device node handling to simplify error paths
Jonathan Cameron
Jonathan.Cameron at Huawei.com
Wed Aug 21 04:48:02 PDT 2024
On Tue, 20 Aug 2024 11:36:32 +0200
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> On 19/08/2024 18:19, Jonathan Cameron wrote:
> > On Mon, 19 Aug 2024 17:13:13 +0100
> > Jonathan Cameron <Jonathan.Cameron at Huawei.com> wrote:
> >
> >> On Fri, 16 Aug 2024 17:09:29 +0200
> >> Krzysztof Kozlowski <krzysztof.kozlowski at linaro.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 at linaro.org>
> >> The original code looks suspect. See below.
> >
> > Whilst here... Why not do similar for state_node to avoid
> > the delayed return check.
> > Existing code
> > {
> > state_node = of_get_cpu_state_node(cpu_node, i - 1);
> > if (!state_node)
> > break;
>
> I don't see how __free() helps here. You can return regardless of __free().
>
> >
> > ret = sbi_dt_parse_state_node(state_node, &states[i]);
> > of_node_put(state_node);
>
> ... and this code is quite easy to read: you get reference and
> immediately release it.
>
> >
> > if (ret)
> > //another bug here on holding cpu_node btw.
> > return ret;
> > pr_debug("sbi-state %#x index %d\n", states[i], i);
> > }
> > //I think only path to this is is early break above.
> > if (i != state_count) {
> > ret = -ENODEV;
> > goto fail;
> > }
> > Can be something like
> >
> > {
> > struct device_node *state_node __free(device_node) =
> > = of_get-cpu_State_nod(cpu_node, i - 1);
> >
> > if (!state_node)
> > return -ENODEV;
> >
> > ret = sbi_dt_parse_state_node(state_node, &states[i]);
> > if (ret)
> > return ret;
> >
> > pr_debug("sbi-state %#x index %d\n", states[i], i);
> > }
> >
>
> Maybe I miss something, but I do not see how the __free() simplifies
> here anything.
Personal preference. To my eyes, it does, but indeed not a huge
advantage.
Jonathan
>
> Best regards,
> Krzysztof
>
More information about the linux-riscv
mailing list