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:

quoted

On Fri, Apr 25, 2025 at 06:30:10PM +0300, Dan Carpenter wrote:

quoted

Whatever happened with this thread from Feb.
https://lore.kernel.org/all/20250207013117.104205-1-zhangzekun11@huawei.com/ (local)

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.
Finding the call sites is the easy part, and we have them already.

quoted

quoted

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

-- 
Regards,

Laurent Pinchart