[lkml]   [2017]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectExpected behavior of set_termios() w.r.t. TX FIFO?
Hi Greg, Jiri, Peter,

I'm wondering what is the expected behavior of calling
uart_ops.set_termios() w.r.t. characters that are already queued in the

- Should it wait (block) until all queued characters have been
transmitted, before changing the UART's settings?
- Should it apply the new settings immediately, affecting the already
queued characters?
- Should it apply the new settings, dropping the already queued
- Is calling uart_ops.set_termios() while the TX FIFO isn't empty
allowed (this can be triggered easily from userspace)?

uart_ops.set_termios() returns void, so there's no way to return an error.

Currently the sh-sci driver blocks until the TX FIFO has been emptied,
which may never happen if hardware flow control is enabled, and the remote
side never asserts CTS, leading to:

NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!

See also "[PATCH 2/2] serial: sh-sci: Fix hang in sci_reset()",

Thanks for your answer!



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

 \ /
  Last update: 2017-03-17 13:29    [W:0.053 / U:2.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site