All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Qianhui Xu" <xiaqinghuan@mail.ustc.edu.cn>
Cc: linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [RFC PATCH v3 2/2] usb: roles: look up role switches attached to a graph endpoint
Date: Mon, 19 Oct 2026 13:26:31 +0000	[thread overview]
Message-ID: <sashiko-outbox-177142@kernel.org> (raw)
In-Reply-To: <20261019131848.344689-3-xiaqinghuan@mail.ustc.edu.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] usb: roles: usb_role_switch_at_endpoint() drops -EPROBE_DEFER
--

commit ed41e724f9aec8ba70adffc81a77e04c561b9932
Author: Qianhui Xu <xiaqinghuan@mail.ustc.edu.cn>

usb: roles: look up role switches attached to a graph endpoint

This patch adds usb_role_switch_at_endpoint() to look up USB role switches
registered on remote OF graph endpoints and calls it from
usb_role_switch_get() and fwnode_usb_role_switch_get().

> diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
> index edec139b68b52..fc739fd61f033 100644
> --- a/drivers/usb/roles/class.c
> +++ b/drivers/usb/roles/class.c
> @@ -157,6 +157,42 @@ usb_role_switch_is_parent(struct fwnode_handle *fwnode)
>  	return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);
>  }
>  
> +/*
> + * Look up a role switch registered against the remote endpoint of one of the
> + * caller's OF graph endpoints.  This is how a connector endpoint that shares a
> + * USB data bus with another connector (for example two Type-C receptacles on a
> + * single DWC3 controller, selected by a GPIO mux) finds its own role switch.
> + */
> +static struct usb_role_switch *
> +usb_role_switch_at_endpoint(struct fwnode_handle *fwnode)
> +{
> +	struct fwnode_handle *ep, *remote, *parent;
> +	struct usb_role_switch *sw;
> +	bool available;
> +
> +	fwnode_graph_for_each_endpoint(fwnode, ep) {
> +		parent = fwnode_graph_get_remote_port_parent(ep);
> +		if (!parent)
> +			continue;
> +		available = fwnode_device_is_available(parent);
> +		fwnode_handle_put(parent);
> +		if (!available)
> +			continue;
> +
> +		remote = fwnode_graph_get_remote_endpoint(ep);
> +		if (!remote)
> +			continue;
> +		sw = usb_role_switch_match(remote, "usb-role-switch", NULL);
> +		fwnode_handle_put(remote);
> +		if (!IS_ERR_OR_NULL(sw)) {
> +			fwnode_handle_put(ep);
> +			return sw;
> +		}

[Severity: High]
What happens in usb_role_switch_at_endpoint() if the consumer probes before
the provider has registered the role switch on the remote endpoint?

Looking at usb_role_switch_match() in drivers/usb/roles/class.c:

    if (id && !fwnode_property_present(fwnode, id))
            return NULL;

    dev = class_find_device_by_fwnode(&role_class, fwnode);

    return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);

it already returns NULL when the "usb-role-switch" property is absent on the
remote endpoint, and returns ERR_PTR(-EPROBE_DEFER) when the property is
present but the switch device has not been registered yet.

Because usb_role_switch_at_endpoint() checks !IS_ERR_OR_NULL(sw) instead of
if (sw), ERR_PTR(-EPROBE_DEFER) is ignored and the function returns NULL.

In usb_role_switch_get() and fwnode_usb_role_switch_get(), if (!sw) then
falls through to device_connection_find_match() and
fwnode_connection_find_match(), which also return NULL because the remote
port parent and phandle properties do not carry "usb-role-switch". Callers
treat a NULL return as having no role switch configured rather than
deferring probe.

Should this check be if (sw) so that ERR_PTR(-EPROBE_DEFER) is returned to
the caller, matching fwnode_graph_devcon_matches() and
usb_role_switch_is_parent()?

> +	}
> +
> +	return NULL;
> +}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019131848.344689-1-xiaqinghuan@mail.ustc.edu.cn?part=2

      reply	other threads:[~2026-10-19 13:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17  8:13 [PATCH v2 0/2] usb: dwc3: support two connectors sharing one HS data bus Qianhui Xu
2026-10-17  8:13 ` [PATCH v2 1/2] dt-bindings: usb: snps,dwc3: describe the two-connector HS data path Qianhui Xu
2026-10-17  8:28   ` sashiko-bot
2026-10-17  8:13 ` [PATCH v2 2/2] usb: dwc3: support two connectors sharing one HS data bus Qianhui Xu
2026-10-17  8:36   ` sashiko-bot
2026-10-19 13:18 ` [RFC PATCH v3 0/2] USB: describe two connectors sharing one DWC3 " Qianhui Xu
2026-10-19 13:18   ` [RFC PATCH v3 1/2] dt-bindings: usb: snps,dwc3: describe two connectors sharing one HS bus Qianhui Xu
2026-10-19 13:29     ` sashiko-bot
2026-10-19 13:18   ` [RFC PATCH v3 2/2] usb: roles: look up role switches attached to a graph endpoint Qianhui Xu
2026-10-19 13:26     ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-177142@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=xiaqinghuan@mail.ustc.edu.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.