Re: [PATCH v9 02/15] device property: Add fwnode_graph_get_next_port_endpoint()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] property: hardcoded endpoint name breaks ACPI graph resolution
--

commit 700ad916c7891ffdfc3636d38b9674d27e6c2c87
Author: Chen-Yu Tsai <wenst@chromium.org>

device property: Add fwnode_graph_get_next_port_endpoint()

This commit introduces fwnode_graph_get_next_port_endpoint() to find endpoint
nodes under a given port firmware node. It iterates through the children of
the port node and returns the first one matching the name "endpoint" to
support checking graph connections.

> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 576488c151810..cf874b8cbe3de 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c

[ ... ]

> +struct fwnode_handle *fwnode_graph_get_next_port_endpoint(const struct fwnode_handle *port,
> +							  struct fwnode_handle *prev)
> +{
> +	do {
> +		prev = fwnode_get_next_child_node(port, prev);
> +		if (fwnode_name_eq(prev, "endpoint"))
> +			break;

[Severity: High]
Does this strict string matching break ACPI graph resolution?

When an ACPI platform uses graph bindings, endpoints are typically named
EPXY (e.g., EP00) rather than "endpoint". They are identified by the
endpoint property instead, as supported in is_acpi_graph_node() and ACPI
DSD documentation.

Because fwnode_graph_get_next_port_endpoint() strictly checks the node name
string with fwnode_name_eq(), it will skip these valid ACPI nodes.

Could this result in silently missing graph connections on ACPI platforms
and functionality loss during device probe?

> +	} while (prev);
> +
> +	return prev;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916075745.3549953-1-wenst@chromium.org?part=2