From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>,
BAREBOX <barebox@lists.infradead.org>
Cc: "Claude Sonnet 4.6" <noreply@anthropic.com>
Subject: Re: [PATCH 2/4] usb: typec: wire USB role changes to OTG device
Date: Mon, 20 Apr 2026 13:08:41 +0200 [thread overview]
Message-ID: <2fd9dab7-40ab-4e75-b6c8-821bded735a0@pengutronix.de> (raw)
In-Reply-To: <20260420-usb-typec-stusb160x-v1-2-5875bbae80ab@pengutronix.de>
Hi,
On 4/20/26 11:02 AM, Sascha Hauer wrote:
> When a Type-C controller reports a USB role change via typec_set_role(),
> find the associated OTG device via the OF graph and set its dr_mode
> accordingly.
>
> Since the Type-C controller may probe before the OTG device registers,
> a late_initcall sweeps all known ports and applies any role that was not
> yet forwarded.
>
> Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/usb/typec/class.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index e03eaccbb9..b88e1c1e46 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -8,10 +8,15 @@
>
> #include <module.h>
> #include <driver.h>
> +#include <init.h>
> #include <linux/kernel.h>
> +#include <linux/list.h>
> #include <linux/usb/role.h>
> #include <linux/usb/typec.h>
> #include <linux/usb/typec_altmode.h>
> +#include <linux/usb/usb.h>
> +#include <linux/device/bus.h>
> +#include <of_graph.h>
> #include <param.h>
>
> enum typec_param_accessory {
> @@ -22,12 +27,16 @@ enum typec_param_accessory {
>
> struct typec_port {
> struct device dev;
> + struct list_head list;
> const struct typec_operations *ops;
> int pwr_role; /* enum typec_role */
> int usb_role; /* enum usb_role role */
> int accessory; /* enum typec_param_accessory */
> + bool otg_role_applied;
> };
>
> +static LIST_HEAD(typec_port_list);
> +
> /**
> * typec_set_pwr_role - Report power role change
> * @port: The USB Type-C Port where the role was changed
> @@ -68,6 +77,41 @@ int typec_set_mode(struct typec_port *port, int mode)
> }
> EXPORT_SYMBOL_GPL(typec_set_mode);
>
> +static bool typec_apply_otg_role(struct typec_port *port)
> +{
> + struct device_node *connector = port->dev.of_node;
> + struct device_node *ep, *remote;
> + struct device *dev;
> + enum usb_dr_mode dr_mode;
> + bool applied = false;
> +
> + if (!IS_ENABLED(CONFIG_USB_OTGDEV) || !connector)
> + return false;
> +
> + if (port->usb_role == USB_ROLE_HOST)
> + dr_mode = USB_DR_MODE_HOST;
> + else if (port->usb_role == USB_ROLE_DEVICE)
> + dr_mode = USB_DR_MODE_PERIPHERAL;
> + else
> + return false;
> +
> + for_each_endpoint_of_node(connector, ep) {
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote)
> + continue;
> +
> + bus_for_each_device(&otg_bus_type, dev) {
> + if (dev->parent && dev->parent->of_node == remote) {
I believe board code could've set the mode before we come here.
Also, I think there must be a way to opt out of this.
Let's assume you load barebox via USB on a Type C port. You may not be
able to yank the cable away fast enough before barebox does the one-way
otg -> peripheral transition.
> + otg_device_set_dr_mode(dev, dr_mode);
> + applied = true;
> + break;
> + }
> + }
> + }
> +
> + return applied;
> +}
> +
> /**
> * typec_set_role - Set USB role for a Type-C connector
> * @port: USB Type-C connector
> @@ -79,10 +123,24 @@ EXPORT_SYMBOL_GPL(typec_set_mode);
> int typec_set_role(struct typec_port *port, enum usb_role role)
> {
> port->usb_role = role;
> + port->otg_role_applied = typec_apply_otg_role(port);
> return 0;
> }
> EXPORT_SYMBOL_GPL(typec_set_role);
>
> +static int typec_apply_otg_roles(void)
> +{
> + struct typec_port *port;
> +
> + list_for_each_entry(port, &typec_port_list, list) {
> + if (!port->otg_role_applied)
> + port->otg_role_applied = typec_apply_otg_role(port);
> + }
> +
> + return 0;
> +}
> +late_initcall(typec_apply_otg_roles);
Does postenvironment not make more sense, so the environment can
override this?
> +
> /**
> * typec_get_drvdata - Return private driver data pointer
> * @port: USB Type-C port
> @@ -165,6 +223,8 @@ struct typec_port *typec_register_port(struct device *parent,
> if (dev->of_node)
> dev->of_node->dev = dev;
>
> + list_add_tail(&port->list, &typec_port_list);
> +
> dev_add_param_enum(dev, "usb_role", param_set_readonly, typec_param_update,
> &port->usb_role, usb_role_names,
> ARRAY_SIZE(usb_role_names), port);
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2026-04-20 11:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 9:02 [PATCH 0/4] usb: typec: STUSB160x support Sascha Hauer
2026-04-20 9:02 ` [PATCH 1/4] usb: otg: Add function to set dr_mode Sascha Hauer
2026-04-20 10:42 ` Ahmad Fatoum
2026-04-20 9:02 ` [PATCH 2/4] usb: typec: wire USB role changes to OTG device Sascha Hauer
2026-04-20 11:08 ` Ahmad Fatoum [this message]
2026-04-20 12:02 ` Sascha Hauer
2026-04-20 9:02 ` [PATCH 3/4] usb: typec: add typec_find_port_power_role() and typec_find_pwr_opmode() Sascha Hauer
2026-04-20 9:02 ` [PATCH 4/4] USB: typec: Add STUSB160x driver Sascha Hauer
2026-04-20 11:14 ` Ahmad Fatoum
2026-04-20 11:30 ` Sascha Hauer
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=2fd9dab7-40ab-4e75-b6c8-821bded735a0@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=noreply@anthropic.com \
--cc=s.hauer@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox