linux-stable.git/drivers/tty, branch linux-3.13.y

tty: Fix low_latency BUG

2014-04-22T23:49:20+00:00

commit a9c3f68f3cd8d55f809fbdb0c138ed061ea1bd25 upstream.

The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.

Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.

However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.

Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.

Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.

Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.

[1] https://lkml.org/lkml/2014/2/20/434

"Yay.. thats an annoying historical pain in the butt gone."
	-- Alan Cox

Reported-by: Beat Bolli 
Reported-by: Pavel Roskin 
Acked-by: David Sterba 
Cc: Grant Edwards 
Cc: Stanislaw Gruszka 
Cc: Hal Murray 
Signed-off-by: Peter Hurley 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: Set correct tty name in 'active' sysfs attribute

2014-04-22T23:49:20+00:00

commit 723abd87f6e536f1353c8f64f621520bc29523a3 upstream.

The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.

There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The ->device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).

Cc: Lennart Poettering 
Cc: Kay Sievers 
Cc: Jiri Slaby 
Signed-off-by: Werner Fink 
Signed-off-by: Hannes Reinecke 
Signed-off-by: David Herrmann 
Signed-off-by: Greg Kroah-Hartman

serial: omap-serial: Move info message to probe function

2014-02-22T21:34:49+00:00

commit ce6acca65ee42c06ac54ec9ba918865d06cee29d upstream.

Currently the info message about a missing wakeirq for uart is printed
every time the serial driver's startup function is called. This happens
multiple times and not just once.

This can cause lots of extra messages at boot time, slowing things down.  It is
caused by commit 2a0b965cfb6e (serial: omap: Add support for optional wake-up)
which was applied for v3.13-rc1.

This patch moves the infomessage to the probe function to display it
only once.

Reported-by: Uwe Kleine-König 
Acked-by: Tony Lindgren 
Signed-off-by: Markus Pargmann 
Acked-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman

vt: Fix secure clear screen

2014-02-22T21:34:49+00:00

commit 0930b0950a8996aa88b0d2ba4bb2bab27cc36bc7 upstream.

\E[3J console code (secure clear screen) needs to update_screen(vc)
in order to write-through blanks into off-screen video memory.

This has been removed accidentally in 3.6 by:

commit 81732c3b2fede049a692e58a7ceabb6d18ffb18c
Author: Jean-François Moine 
Date:   Thu Sep 6 19:24:13 2012 +0200

    tty vt: Fix line garbage in virtual console on command line edition

Signed-off-by: Petr Písař 
Signed-off-by: Greg Kroah-Hartman

n_tty: Fix stale echo output

2014-02-22T21:34:47+00:00

commit e2613be5093d04e6589924d36a1e363eef3c87c7 upstream.

When echoes cannot be flushed to output (usually because the tty
has no more write room) and L_ECHO is subsequently turned off, then
when L_ECHO is turned back on, stale echoes are output.

Output completed echoes regardless of the L_ECHO setting:
  1. before normal writes to that tty
  2. if the tty was stopped by soft flow control and is being
     restarted

Reported-by: Mikulas Patocka 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: n_gsm: Fix for modems with brk in modem status control

2014-02-22T21:34:47+00:00

commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream.

3GPP TS 07.10 states in section 5.4.6.3.7:
"The length byte contains the value 2 or 3 ... depending on the break
signal." The break byte is optional and if it is sent, the length is
3. In fact the driver was not able to work with modems that send this
break byte in their modem status control message. If the modem just
sends the break byte if it is really set, then weird things might
happen.
The code for deconding the modem status to the internal linux
presentation in gsm_process_modem has already a big comment about
this 2 or 3 byte length thing and it is already able to decode the
brk, but the code calling the gsm_process_modem function in
gsm_control_modem does not encode it and hand it over the right way.
This patch fixes this.
Without this fix if the modem sends the brk byte in it's modem status
control message the driver will hang when opening a muxed channel.

Signed-off-by: Lars Poeschel 
Signed-off-by: Greg Kroah-Hartman

serial: sirf: fix kernel panic caused by unpaired spinlock

2014-02-22T21:34:46+00:00

commit fb78b811422cd2d8c8605949cc4cc13618347ad5 upstream.

commit 8b9ade9f74f8a279 coming from Viresh Kumar "tty: serial: sirfsoc: drop
uart_port->lock before calling tty_flip_buffer_push()" broke sirfsoc uart
driver by knic:

	[    5.129122] BUG: spinlock already unlocked on CPU#0, ip6tables/1331
	[    5.132554]  lock: sirfsoc_uart_ports+0x4/0x8a0, .magic: dead4ead,
	.owner: /-1, .owner_cpu: -1
	[    5.141651] CPU: 0 PID: 1331 Comm: ip6tables Tainted: G
	W  O 3.10.16 #3
	[    5.148866] [] (unwind_backtrace+0x0/0xe0) from
	[] (show_stack+0x10/0x14)
	[    5.157362] [] (show_stack+0x10/0x14) from
	[] (do_raw_spin_unlock+0x40/0xc8)
	[    5.166125] [] (do_raw_spin_unlock+0x40/0xc8) from
	[] (_raw_spin_unlock+0x8/0x40)
	[    5.175322] [] (_raw_spin_unlock+0x8/0x40) from
	[] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0)
	[    5.185120] []
	(sirfsoc_uart_pio_rx_chars+0xa4/0xc0) from []
	(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0)
	[    5.195875] []
	(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) from []
	(tasklet_action+0x8c/0xec)
	[    5.205673] [] (tasklet_action+0x8c/0xec) from
	[] (__do_softirq+0xec/0x1d4)
	[    5.214347] [] (__do_softirq+0xec/0x1d4) from
	[] (do_softirq+0x48/0x54)
	[    5.222674] [] (do_softirq+0x48/0x54) from
	[] (irq_exit+0x74/0xc0)
	[    5.230573] [] (irq_exit+0x74/0xc0) from
	[] (handle_IRQ+0x6c/0x90)
	[    5.238465] [] (handle_IRQ+0x6c/0x90) from
	[] (__irq_svc+0x40/0x70)
	[    5.246446] [] (__irq_svc+0x40/0x70) from
	[] (mark_page_accessed+0xc/0x68)
	[    5.255034] [] (mark_page_accessed+0xc/0x68) from
	[] (unmap_single_vma+0x3bc/0x550)
	[    5.264402] [] (unmap_single_vma+0x3bc/0x550) from
	[] (unmap_vmas+0x44/0x54)
	[    5.273164] [] (unmap_vmas+0x44/0x54) from
	[] (exit_mmap+0xc4/0x1e0)
	[    5.281233] [] (exit_mmap+0xc4/0x1e0) from
	[] (mmput+0x3c/0xdc)
	[    5.288868] [] (mmput+0x3c/0xdc) from []
	(do_exit+0x30c/0x828)
	[    5.296413] [] (do_exit+0x30c/0x828) from
	[] (do_group_exit+0x4c/0xb0)
	[    5.304653] [] (do_group_exit+0x4c/0xb0) from
	[] (__wake_up_parent+0x0/0x18)

Root cause:
the commit dropped uart_port->lock before calling tty_flip_buffer_push(), but in sirfsoc-uart,
sirfsoc_uart_pio_rx_chars() can be called by sirfsoc_rx_tmo_process_tl(). here uart_port->lock
has not been taken yet. so that caused unpaired lock/unlock.

Solution:
This patch is doing a quick fix for that, it adds spin_lock/unlock(&port->lock) protect to
sirfsoc_uart_pio_rx_chars() in sirfsoc_rx_tmo_process_tl() to keep spin_lock/unlock in pair.

Signed-off-by: Qipan Li 
Signed-off-by: Barry Song 
Signed-off-by: Greg Kroah-Hartman

drivers/tty: ehv_bytechan fails to build as a module

2014-02-06T19:34:07+00:00

commit a183d3ae63c08186477d2b0ef2798d47d10add4b upstream.

ehv_bytechan is marked tristate but fails to build as a module:

drivers/tty/ehv_bytechan.c:363:1: error: type defaults to ‘int’ in declaration of ‘console_initcall’ [-Werror=implicit-int]

It doesn't make much sense for a console driver to be built as
a module, so change it to a bool.

Signed-off-by: Anton Blanchard 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Scott Wood 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: enable UART_BUG_NOMSR for Tegra

2014-02-06T19:34:00+00:00

commit 3685f19e07802ec4207b52465c408f185b66490e upstream.

Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
their MODEM-control signals tied off to a static state. However UARTs A
and B can optionally route those signals to/from package pins, depending
on the exact pinmux configuration.

When these signals are not routed to package pins, false interrupts may
trigger either temporarily, or permanently, all while not showing up in
the IIR; it will read as NO_INT. This will eventually lead to the UART
IRQ being disabled due to unhandled interrupts. When this happens, the
kernel may print e.g.:

    irq 68: nobody cared (try booting with the "irqpoll" option)

In order to prevent this, enable UART_BUG_NOMSR. This prevents
UART_IER_MSI from being enabled, which prevents the false interrupts
from triggering.

In practice, this is not needed under any of the following conditions:

* On Tegra chips after Tegra30, since the HW bug has apparently been
  fixed.

* On UARTs C..E since their MODEM control signals are tied to the correct
  static state which doesn't trigger the issue.

* On UARTs A..B if the MODEM control signals are routed out to package
  pins, since they will then carry valid signals.

However, we ignore these exceptions for now, since they are only relevant
if a board actually hooks up more than a 4-wire UART, and no currently
supported board does this. If we ever support a board that does, we can
refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
into account, and/or read a flag from DT/... that indicates that the
board has hooked up and pinmux'd more than a 4-wire UART.

Reported-by: Olof Johansson  # autotester
Signed-off-by: Stephen Warren 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix initialisation of Quatech cards with the AMCC PCI chip

2014-02-06T19:34:00+00:00

commit 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream.

Fix the initialisation of older Quatech serial cards which are fitted with
the AMCC PCI Matchmaker interface chip.

Signed-off-by: Jonathan Woithe (jwoithe@just42.net)
Signed-off-by: Greg Kroah-Hartman