On Tue, Nov 25, 2025 at 08:53:17AM +0100, Łukasz Bartosik wrote:
On Mon, Nov 24, 2025 at 10:11 AM Jiri Slaby jirislaby@kernel.org wrote:
On 24. 11. 25, 8:48, Mathias Nyman wrote:
On 11/24/25 08:42, Jiri Slaby wrote:
Hmm, CCing TTY MAINTAINERS entry would not hurt.
Fair point. I will keep it in mind in the future.
On 19. 11. 25, 22:29, Ł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.
indefinitely
Thanks for spotting this.
This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail.
Cc: stable@vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik ukaszb@chromium.org
Changes in v2:
- Replaced tty_hangup() with tty_vhangup()
Why exactly?
I recommended using tty_vhangup(), well actually tty_port_tty_vhangup() to solve issue '2' you pointed out. To me it looks like tty_vhangup() is synchronous so it won't schedule hangup work and should be safe to call right before we destroy the port.
Oops, right, my cscope DB was old and lead me to tty_hangup() instead (that schedules).
- you schedule a tty hangup work and destroy the port right after:
tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false;You should to elaborate how this is supposed to work?
Does tty_port_tty_vhangup() work here? it
- checks if tty is NULL
- is synchronous and should be safe to call before tty_unregister_device()
Yes, this works for me.
Greg should I send v3 with typo fix indifinitely -> indefinitely and elaborate on the tty_hangup() -> tty_vhangup() replacement in changes ?
As this is already in my tree, a fixup on top of that would be good.
thanks,
greg k-h