Re: [PATCH net-next v2 1/4] of: property: skip links without a consumer node

Saravana Kannan <[email protected]>
Newsgroups dev.linux.lists.driver-core,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <CACRMN=eU_C=sSXxoR_WY-LMPwD6H-bi366TXsbbDt0tPBmPA=A@mail.gmail.com>
On Sun, Aug 16, 2026 at 5:00 PM James Hilliard
<[email protected]> wrote:
>
> Supplier bindings can map a property node to the device node which
> consumes the referenced resource. The remote-endpoint binding uses
> of_graph_get_port_parent(), which can return NULL for a malformed graph
> node without its expected parents.
>
> of_link_property() currently passes that NULL node through to
> fwnode_link_add(), which dereferences the consumer while adding the
> link.
>
> Only create the link when the binding resolved a consumer node. A
> malformed graph property then creates no dependency instead of crashing
> while fw_devlink parses the tree.

Is this a real issue? If it's upstream, should  we fix the DT? If it's
off-tree/down stream, should we care?

If it was reported, can you please add a reported by and link to the report?

>
> Fixes: f7514a663016 ("of: property: fw_devlink: Add support for remote-endpoint")
> Signed-off-by: James Hilliard <[email protected]>
> ---
>  drivers/of/property.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 72cf12907de0..38c0c7dc428a 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1620,7 +1620,9 @@ static int of_link_property(struct device_node *con_np, const char *prop_name)
>
>                         matched = true;
>                         i++;
> -                       of_link_to_phandle(con_dev_np, phandle, s->fwlink_flags);
> +                       if (con_dev_np)
> +                               of_link_to_phandle(con_dev_np, phandle,
> +                                                  s->fwlink_flags);

This shouldn't be a normal case. Can you please add a WARN_ON() for this case?

Assuming we choose to fix this, I'd recommend sending this out as a
separate patch so it's not slowed down by the more complicated patch
series.

-Saravana

>                         of_node_put(phandle);
>                 }
>                 s++;

>
> --
> 2.53.0
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.