Hi Łukasz
On 11/14/25 17:01, Łukasz Bartosik wrote:
From: Łukasz Bartosik ukaszb@chromium.org
When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely.
This fix adds a tty_hangup() call in xhci_dbc_tty_unregister_device(). The tty_hangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail.
Nice catch
Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik ukaszb@chromium.org
drivers/usb/host/xhci-dbgtty.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index d894081d8d15..6ea31af576c7 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -535,6 +535,13 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return;
- /*
* Hang up the TTY. This wakes up any blocked* writers and causes subsequent writes to fail.*/- if (port->port.tty)
tty_hangup(port->port.tty);
I'm not a tty expert but would the tty_port_tty_vhangup(&port->port) make sense here?
No need to check for port->port.tty, and it does all the needed locking and tty reference counting.
It is also synchronous which should probably be ok as this is either called from a delayed workqueue, during suspend, or remove()
Thanks Mathias