linux-toradex.git/drivers/tty, branch v3.0.26

drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer

2012-02-13T19:06:05+00:00

commit cbcb8346054073d000ecac324763372d6abd44ac upstream.

KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
with a 64bit kernel if the font width is not 8.

This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
con_font_get return EIO in such case.

This flag should *not* be set for KDFONTOP, since it's actually the whole
point of this flag (see comment in con_font_set for instance).

Signed-off-by: Samuel Thibault 
Reviewed-by: Arnd Bergmann 
Cc: Arthur Taylor 
Cc: Jiri Slaby 
Cc: Jiri Olsa 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

jsm: Fixed EEH recovery error

2012-02-03T17:19:00+00:00

commit 26aa38cafae0dbef3b2fe75ea487c83313c36d45 upstream.

There was an error on the jsm driver that would cause it to be unable to
recover after a second error is detected.

At the first error, the device recovers properly:

[72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
[72521.485695] EEH: This PCI device has failed 1 times in the last hour:
...
[72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
[72532.105689] jsm: Port 3 added

However, at the second error, it cascades until EEH disables the device:

[72631.229549] Call Trace:
...
[72641.725687] jsm: Port 3 added
[72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
[72641.725698] EEH: This PCI device has failed 3 times in the last hour:

It was caused because the PCI state was not being saved after the first
restore. Therefore, at the second recovery the PCI state would not be
restored.

Signed-off-by: Lucas Kannebley Tavares 
Signed-off-by: Breno Leitao 
Acked-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Greg Kroah-Hartman

serial: amba-pl011: lock console writes against interrupts

2012-02-03T17:19:00+00:00

commit ef605fdb33883d687cff5ba75095a91b313b4966 upstream.

Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.

Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.

The checks for sysrq and oops_in_progress are taken
from 8250.c.

Signed-off-by: Rabin Vincent 
Reviewed-by: Srinidhi Kasagar 
Reviewed-by: Bibek Basu 
Reviewed-by: Shreshtha Kumar Sahu 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

TTY: fix UV serial console regression

2012-02-03T17:19:00+00:00

commit 0eee50af5b13e00b3fb7a5fe8480419a71b8235d upstream.

Commit 74c2107759d (serial: Use block_til_ready helper) and its fixup
3f582b8c110 (serial: fix termios settings in open) introduced a
regression on UV systems. The serial eventually freezes while being
used. It's completely unpredictable and sometimes needs a heap of
traffic to happen first.

To reproduce this, yast installation was used as it turned out to be
pretty reliable in reproducing. Especially during installation process
where one doesn't have an SSH daemon running. And no monitor as the HW
is completely headless. So this was fun to find. Given the machine
doesn't boot on vanilla before 2.6.36 final. (And the commits above
are older.)

Unless there is some bad race in the code, the hardware seems to be
pretty broken. Otherwise pure MSR read should not cause such a bug,
or?

So to prevent the bug, revert to the old behavior. I.e. read modem
status only if we really have to -- for non-CLOCAL set serials.
Non-CLOCAL works on this hardware OK, I tried. See? I don't.

And document that shit.

Signed-off-by: Jiri Slaby 
References: https://lkml.org/lkml/2011/12/6/573
References: https://bugzilla.novell.com/show_bug.cgi?id=718518
Signed-off-by: Greg Kroah-Hartman

atmel_serial: fix spinlock lockup in RS485 code

2012-01-12T19:35:07+00:00

commit dbf1115d3f8c7052788aa4e6e46abd27f3b3eeba upstream.

Patch to fix a spinlock lockup in the driver that sometimes happens when the
tasklet starts.

Signed-off-by: Claudio Scordino 
Signed-off-by: Dave Bender 
Tested-by: Dave Bender 
Acked-by: Nicolas Ferre 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, wait for ldisc infinitely in hangup

2011-11-26T17:09:58+00:00

commit 0c73c08ec73dbe080b9ec56696ee21d32754d918 upstream.

For /dev/console case, we do not kill all ldisc users. It's due to
redirected_tty_write test in __tty_hangup. In that case there still
might be a process waiting e.g. in n_tty_read for input.

We wait for such processes to disappear. The problem is that we use a
timeout. After this timeout, we continue closing the ldisc and start
freeing tty resources. It obviously leads to crashes when the other
process is woken.

So to fix this, we wait infinitely before reiniting the ldisc. (The
tiocsetd remains untouched -- times out after 5s.)

This is nicely reproducible with this run from shell:
  exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
and stopping a getty like:
  systemctl stop serial-getty@ttyS0.service

The crash proper may be produced only under load or with constified
timing the same as for 92f6fa09b.

Signed-off-by: Jiri Slaby 
Cc: Dave Young 
Cc: Dave Jones 
Cc: Ben Hutchings 
Cc: Dmitriy Matrosov 
Cc: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, move wait idle to caller

2011-11-26T17:09:58+00:00

commit 300420722e0734a4254f3b634e0f82664495d210 upstream.

It is the only place where reinit is called from. And we really need
to wait for the old ldisc to go once. Actually this is the place where
the waiting originally was (before removed and re-added later).

This will make the fix in the following patch easier to implement.

Signed-off-by: Jiri Slaby 
Cc: Dave Young 
Cc: Dave Jones 
Cc: Ben Hutchings 
Cc: Dmitriy Matrosov 
Cc: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

TTY: ldisc, allow waiting for ldisc arbitrarily long

2011-11-26T17:09:58+00:00

commit df92d0561de364de53c42abc5d43e04ab6f326a5 upstream.

To fix a nasty bug in ldisc hup vs. reinit we need to wait infinitely
long for ldisc to be gone. So here we add a parameter to
tty_ldisc_wait_idle to allow that.

This is only a preparation for the real fix which is done in the
following patches.

Signed-off-by: Jiri Slaby 
Cc: Dave Young 
Cc: Dave Jones 
Cc: Ben Hutchings 
Cc: Dmitriy Matrosov 
Cc: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: hvc_dcc: Fix duplicate character inputs

2011-11-26T17:09:57+00:00

commit c2a3e84f950e7ddba1f3914b005861d46ae60359 upstream.

Reading from the DCC grabs a character from the buffer and
clears the status bit. Since this is a context-changing
operation, instructions following the character read that rely on
the status bit being accurate need to be synchronized with an
ISB.

In this case, the status bit check needs to execute after the
character read otherwise we run the risk of reading the character
and checking the status bit before the read can clear the status
bit in the first place. When this happens, the user will see the
same character they typed twice, instead of once.

Add an ISB after the read and the write, so that the status check
is synchronized with the read/write operations.

Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

pch_uart: Support new device LAPIS Semiconductor ML7831 IOH

2011-11-26T17:09:57+00:00

commit 8249f743f732ccbc3056428945ab1d9bd36d46bf upstream.

ML7831 is companion chip for Intel Atom E6xx series.

Signed-off-by: Tomoya MORINAGA 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman