| Message ID | 20241031175404.114773-4-sebastian.reichel@collabora.com |
|---|---|
| State | New |
| Delegated to: | Marek Vasut |
| Headers | show |
| Series | USB-PD TCPM improvements | expand |
diff --git a/drivers/usb/tcpm/tcpm.c b/drivers/usb/tcpm/tcpm.c index 786d92fa4c6f..909fe2ef4fcb 100644 --- a/drivers/usb/tcpm/tcpm.c +++ b/drivers/usb/tcpm/tcpm.c @@ -1711,6 +1711,8 @@ static void run_state_machine(struct udevice *dev) /* Hard_Reset states */ case HARD_RESET_SEND: + if (!port->self_powered && port->port_type == TYPEC_PORT_SNK) + dev_err(dev, "Initiating hard-reset, which might result in machine power-loss.\n"); tcpm_pd_transmit(dev, TCPC_TX_HARD_RESET, NULL); tcpm_set_state(dev, HARD_RESET_START, 0); port->wait_dr_swap_message = false;
A USB-PD hard reset involves removing the voltage from VBUS for some time. So basically it has the same effect as removing the USB-C plug for a short moment. If the machine is powered from the USB-C port and does not have a fallback supply (e.g. a battery), this will result in a full machine reset due to power loss. Ideally we want to avoid triggering a hard reset on these boards. A non-working USB-C port is probably better than unplanned reboots. But boards with a backup supply should do the hard reset to get everything working again. In theory it would be enough to check the self_powered property, but it seems the property might not be configured consistently enough in system firmwares. USB-PD hard resets should happen rarely in general, so let's at least print an error message before the potential board reset happens. This is also useful, since it immediately gives away which device triggered the hard reset. Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> --- drivers/usb/tcpm/tcpm.c | 2 ++ 1 file changed, 2 insertions(+)