linux/drivers/tty/serial, branch v3.12.10

serial: 8250: enable UART_BUG_NOMSR for Tegra

2014-02-06T19:22:17Z

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:22:17Z

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

serial: add support for 200 v3 series Titan card

2014-02-06T19:22:17Z

commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream. Signed-off-by: Yegor Yefremov Signed-off-by: Greg Kroah-Hartman

tty/serial: at91: disable uart timer at start of shutdown

2014-02-06T19:22:17Z

commit 8bc661bfc0c2d221e209f4205bdaaf574d50100c upstream. The uart timer will schedule a tasklet when it fires. It is possible that it can fire inside _shutdown before it is killed in the dma and pdc cleanup routines. This causes a tasklet that exists after the port is shutdown, so when the kernel finally executes it, it panics as the tty port is NULL. This is a somewhat rare condition but its possible if a program keeps on opening/closing the port. It has been observed in particular with systemd boot messages that were causing a kernel panic because of this behavior. Moving the timer deletion to the beginning of the function stops a tasklet from being scheduled unexpectedly. Signed-off-by: Marek Roszko [nicolas.ferre@atmel.com: modify commit message, call setup_timer() in any case] Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

tty/serial: at91: reset rx_ring when port is shutdown

2014-02-06T19:22:17Z

commit bb7e73c598fb226c75f7625088a8f6a45a0fc892 upstream. When using RX DMA, the driver won't pass any data to the uart layer until the buffer is flipped. When the port is shutdown, the dma buffers are unmapped, but the head and tail of the ring buffer are not reseted. Since the serial console will keep the port open, this will only present itself when the uart is not shared. To reproduce the issue, with an unpatched driver, run a getty on /dev/ttyS0 with no serial console and exit. Getty will exit, and when the new one returns you will be unable to log in. If you hold down a key long enough to fill the DMA buffer and flip it, you can then log in. Signed-off-by: Mark Deneen Acked-by: Leilei Zhao [nicolas.ferre@atmel.com: adapt to mainline kernel, handle !DMA case] Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

tty/serial: at91: fix race condition in atmel_serial_remove

2014-02-06T19:22:17Z

commit f50c995f9ebf064cea1368bf361c4e29679415b4 upstream. The _remove callback could be called when a tasklet is scheduled. tasklet_kill was called inside the function in order to free up any scheduled tasklets. However it was called after uart_remove_one_port which destroys tty references needed in the port for atmel_tasklet_func. Simply putting the tasklet_kill at the start of the function will prevent this conflict. Signed-off-by: Marek Roszko Acked-by: Leilei Zhao Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

tty/serial: at91: Handle shutdown more safely

2014-02-06T19:22:17Z

commit 0cc7c6c7916b1b6f34350ff1473b80b9f7e459c0 upstream. Interrupts were being cleaned up late in the shutdown handler, it is possible that an interrupt can occur and schedule a tasklet that runs after the port is cleaned up. There is a null dereference due to this race condition with the following stacktrace: [] (atmel_tasklet_func+0x514/0x814) from [] (tasklet_action+0x70/0xa8) [] (tasklet_action+0x70/0xa8) from [] (__do_softirq+0x90/0x144) [] (__do_softirq+0x90/0x144) from [] (irq_exit+0x40/0x4c) [] (irq_exit+0x40/0x4c) from [] (handle_IRQ+0x64/0x84) [] (handle_IRQ+0x64/0x84) from [] (__irq_svc+0x40/0x50) [] (__irq_svc+0x40/0x50) from [] (atmel_rx_dma_release+0x88/0xb8) [] (atmel_rx_dma_release+0x88/0xb8) from [] (atmel_shutdown+0x104/0x160) [] (atmel_shutdown+0x104/0x160) from [] (uart_port_shutdown+0x2c/0x38) Signed-off-by: Marek Roszko Acked-by: Leilei Zhao Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

serial: amba-pl011: use port lock to guard control register access

2014-01-25T16:49:29Z

commit fe43390702a1b5741fdf217063b05c7612b38303 upstream. When the pl011 is being used for a console, pl011_console_write forces the control register (CR) to enable the UART for transmission and then restores this to the original value afterwards. It does this while holding the port lock. Unfortunately, when the uart is started or shutdown - say in response to userland using the serial device for a terminal - then this updates the control register without any locking. This means we can have pl011_console_write Save CR pl011_startup Initialise CR, e.g. enable receive pl011_console_write Restore old CR with receive not enabled this result is a serial port which doesn't respond to any input. A similar race in reverse could happen when the device is shutdown. We can fix these problems by taking the port lock when updating CR. Signed-off-by: Jon Medhurst Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: add new ACPI IDs

2014-01-09T20:25:08Z

commit d24c195f90cb1adb178d26d84c722d4b9e551e05 upstream. Newer Intel PCHs with LPSS have the same Designware controllers than Haswell but ACPI IDs are different. Add these IDs to the driver list. Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

TTY: pmac_zilog, check existence of ports in pmz_console_init()

2014-01-09T20:25:07Z

commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream. When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0" on the kernel command line, it crashes with: Unable to handle kernel NULL pointer dereference at virtual address (null) Oops: 00000000 PC: [<0013ad28>] __pmz_startup+0x32/0x2a0 ... Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4 The normal tty driver doesn't crash, because init_pmz() checks pmz_ports_count again after calling pmz_probe(). In the serial console initialization path, pmz_console_init() doesn't do this, causing the driver to crash later. Add a check for pmz_ports_count to fix this. Signed-off-by: Geert Uytterhoeven Cc: Finn Thain Cc: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman