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

serial: PL011: move interrupt clearing

2012-04-22T22:31:11+00:00

commit c3d8b76f61586714cdc5f219ba45592a54caaa55 upstream.

Commit 360f748b204275229f8398cb2f9f53955db1503b
"serial: PL011: clear pending interrupts"
attempts to clear interrupts by writing to a
yet-unassigned memory address. This fixes the issue.

The breaking patch is marked for stable so should be
carried along with the other patch.

Cc: Shreshtha Kumar Sahu 
Cc: Russell King 
Cc: Nicolas Pitre 
Reported-by: Viresh Kumar 
Signed-off-by: Linus Walleij 
Tested-by: Grant Likely 
Signed-off-by: Greg Kroah-Hartman

serial: PL011: clear pending interrupts

2012-04-22T22:31:11+00:00

commit 9b96fbacda34079dea0638ee1e92c56286f6114a upstream.

Chanho Min reported that when the boot loader transfers
control to the kernel, there may be pending interrupts
causing the UART to lock up in an eternal loop trying to
pick tokens from the FIFO (since the RX interrupt flag
indicates there are tokens) while in practice there are
no tokens - in fact there is only a pending IRQ flag.

This patch address the issue with a combination of two
patches suggested by Russell King that clears and mask
all interrupts at probe() and clears any pending error
and RX interrupts at port startup time.

We suspect the spurious interrupts are a side-effect of
switching the UART from FIFO to non-FIFO mode.

Cc: Shreshtha Kumar Sahu 
Reported-by: Chanho Min 
Suggested-by: Russell King 
Signed-off-by: Linus Walleij 
Reviewed-by: Jong-Sung Kim 
Signed-off-by: Greg Kroah-Hartman

pch_uart: Fix MSI setting issue

2012-04-22T22:31:01+00:00

commit 867c902e07d5677e2a5b54c0435e589513abde48 upstream.

The following patch (MSI setting) is not enough.

commit e463595fd9c752fa4bf06b47df93ef9ade3c7cf0
Author: Alexander Stein 
Date:   Mon Jul 4 08:58:31 2011 +0200

    pch_uart: Add MSI support

    Signed-off-by: Alexander Stein 
    Signed-off-by: Greg Kroah-Hartman 

To enable MSI mode, PCI bus-mastering must be enabled.
This patch enables the setting.

cc: Alexander Stein 
Signed-off-by: Tomoya MORINAGA 
Signed-off-by: Greg Kroah-Hartman

tty: serial: altera_uart: Check for NULL platform_data in probe.

2012-04-22T22:31:00+00:00

commit acede70d6561f2d042d9dbb153d9a3469479c0ed upstream.

Follow altera_jtag_uart.  This fixes a crash if there is a mistake in the DTS.

Signed-off-by: Yuriy Kozlov 
Signed-off-by: Tobias Klauser 
Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: fix a race of DMA submit_tx on transfer

2012-04-02T16:53:10+00:00

commit 49d4bcaddca977fffdea8b0b71f6e5da96dac78e upstream.

When DMA is enabled, sh-sci transfer begins with
 uart_start()
  sci_start_tx()
    if (cookie_tx < 0) schedule_work()
Then, starts DMA when wq scheduled, -- (A)
 process_one_work()
  work_fn_rx()
   cookie_tx = desc->submit_tx()
And finishes when DMA transfer ends, -- (B)
 sci_dma_tx_complete()
  async_tx_ack()
  cookie_tx = -EINVAL
  (possible another schedule_work())

This A to B sequence is not reentrant, since controlling variables
(for example, cookie_tx above) are not queues nor lists. So, they
must be invoked as A B A B..., otherwise results in kernel crash.

To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0
(represents "not used") to call schedule_work().
But cookie_tx will not be set (to a cookie, also means "used") until
in the middle of work queue scheduled function work_fn_tx().

This gap between the test and set allows the breakage of the sequence
under the very frequently call of uart_start().
Another gap between async_tx_ack() and another schedule_work() results
in the same issue, too.

This patch introduces a new condition "cookie_tx == 0" just to mark
it is "busy" and assign it within spin-locked region to fill the gaps.

Signed-off-by: Takashi Yoshii 
Reviewed-by: Guennadi Liakhovetski 
Signed-off-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

TTY: Wrong unicode value copied in con_set_unimap()

2012-04-02T16:52:31+00:00

commit 4a4c61b7ce26bfc9d49ea4bd121d52114bad9f99 upstream.

Bugzilla 40012: PIO_UNIMAP bug: error updating Unicode-to-font map
https://bugzilla.kernel.org/show_bug.cgi?id=40012

The unicode font map for the virtual console is a 32x32x64 table which
allocates rows dynamically as entries are added.  The unicode value
increases sequentially and should count all entries even in empty
rows.  The defect is when copying the unicode font map in con_set_unimap(),
the unicode value is not incremented properly.  The wrong unicode value
is entered in the new font map.

Signed-off-by: Liz Clark 
Signed-off-by: Greg Kroah-Hartman

tty: moxa: fix bit test in moxa_start()

2012-04-02T16:52:31+00:00

commit 58112dfbfe02d803566a2c6c8bd97b5fa3c62cdc upstream.

This is supposed to be doing a shift before the comparison instead of
just doing a bitwise AND directly.  The current code means the start()
just returns without doing anything.

Signed-off-by: Dan Carpenter 
Acked-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

tty/powerpc: early udbg consoles can't be modules

2012-03-12T19:31:26+00:00

commit f21c6d4a49179f91fd70a41382382f08c780d425 upstream.

Fixes these build errors:

ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined!
ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined!

Cc: Timur Tabi 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Greg Kroah-Hartman

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

2012-02-13T19:16:52+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:22:07+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