Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1603268 > unrolled thread

Expected behavior of set_termios() w.r.t. TX FIFO?

Back to article view | Back to linux.kernel

Contents

  Expected behavior of set_termios() w.r.t. TX FIFO? Geert Uytterhoeven <geert@linux-m68k.org> - 2017-03-17 13:30 +0100
    Re: Expected behavior of set_termios() w.r.t. TX FIFO? Greg KH <gregkh@linuxfoundation.org> - 2017-03-18 12:10 +0100

#1603268 — Expected 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
UART's TX FIFO.

  - 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
    characters?
  - 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()",
https://lkml.org/lkml/2016/12/2/225).

Thanks for your answer!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

[toc] | [next] | [standalone]

#1603765

On Fri, Mar 17, 2017 at 01:28:39PM +0100, Geert Uytterhoeven wrote:
> 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
> UART's TX FIFO.
> 
>   - 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
>     characters?
>   - 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()",
> https://lkml.org/lkml/2016/12/2/225).
> 
> Thanks for your answer!

I think this has come up in the past, and due to the problem you have
found (could be waiting forever due to flow control), the answer was
just to set the new settings and not wait for anything to be flushed out
of the uart.

If a user sends a bunch of data, and then changes settings, without
first waiting for the data to be sent, then I feel they deserve the
uncertainty they will get :)

Hope this helps,

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web