[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0ItIQWHOGL-GTi8@surfacebook.localdomain>
Date: Sat, 23 Nov 2024 21:29:37 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Javier Carrasco <javier.carrasco.cruz@...il.com>
Cc: Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Gene Chen <gene_chen@...htek.com>,
Jacek Anaszewski <jacek.anaszewski@...il.com>,
Bartosz Golaszewski <brgl@...ev.pl>, Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
stable@...r.kernel.org
Subject: Re: [PATCH 00/18] leds: switch to device_for_each_child_node_scoped()
Fri, Sep 27, 2024 at 01:20:51AM +0200, Javier Carrasco kirjoitti:
> This series switches from the device_for_each_child_node() macro to its
> scoped variant, which in general makes the code more robust if new early
> exits are added to the loops, because there is no need for explicit
> calls to fwnode_handle_put(). Depending on the complexity of the loop
> and its error handling, the code gets simplified and it gets easier to
> follow.
>
> The non-scoped variant of the macro is error-prone, and it has been the
> source of multiple bugs where the child node refcount was not
> decremented accordingly in error paths within the loops. The first patch
> of this series is a good example, which fixes that kind of bug that is
> regularly found in node iterators.
>
> The uses of device_for_each_child_node() with no early exits have been
> left untouched because their simpilicty justifies the non-scoped
> variant.
>
> Note that the child node is now declared in the macro, and therefore the
> explicit declaration is no longer required.
>
> The general functionality should not be affected by this modification.
> If functional changes are found, please report them back as errors.
Thank you for this series. It may now benefit from the next steps:
1) converting to return dev_err_probe() or dev_warn_probe() directly since
the goto had been replaced by direct return, hence saving even more LoCs;
2) dropping or refactoring the complex conditions due to your nice series
being applied.
I'll comment individually on some to show what I meant by the above.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists