On Tue, Jun 10, 2025 at 11:03:39PM +0300, Laurent Pinchart wrote: > On Tue, Jun 10, 2025 at 10:39:31PM +0300, Andy Shevchenko wrote: > > On Fri, Apr 25, 2025 at 08:07:32PM +0300, Laurent Pinchart wrote: > > > On Fri, Apr 25, 2025 at 06:30:10PM +0300, Dan Carpenter wrote: > > > > Whatever happened with this thread from Feb. > > > > https://lore.kernel.org/all/20250207013117.104205-1-zhangzeku...@huawei.com/ > > > > > > > > The issue was that people weren't expecting of_find_node_by_name() to > > > > drop the reference on the of_node. The patchset introduced a wrapper > > > > which basically worked as expected except no liked the naming. > > > > Krzysztof > > > > suggested that maybe the callers should be using of_get_child_by_name() > > > > instead. > > > > > > My conclusion is that most of the users of of_find_node_by_name() with a > > > non-NULL first argument are wrong, and should be replaced by > > > of_get_child_by_name(). We need a volunteer to do that work. > > > > Wouldn't be coccinelle a good worker for this job done? > > It's not mechanical work, every single user need to be audited manually.
Sure, but at least it can do some job that can be done automatically. > Finding the call sites is the easy part, and we have them already. > > > > I created a Smatch warning for this and here are the four issues it > > > > found. The line numbers are from linux-next. > > > > > > > > drivers/net/ethernet/broadcom/asp2/bcmasp.c:1370 bcmasp_probe() warn: > > > > 'dev->of_node' was not incremented > > > > drivers/net/pse-pd/tps23881.c:505 tps23881_get_of_channels() warn: > > > > 'priv->np' was not incremented > > > > drivers/media/platform/qcom/venus/core.c:301 venus_add_video_core() > > > > warn: 'dev->of_node' was not incremented > > > > drivers/regulator/tps6594-regulator.c:618 tps6594_regulator_probe() > > > > warn: 'tps->dev->of_node' was not incremented -- With Best Regards, Andy Shevchenko
