user/sven/linux.git/drivers/tty, branch v4.0.3

tty/serial: at91: maxburst was missing for dma transfers

2015-05-13T12:14:28Z

commit a8d4e01637902311c5643b69a5c80e2805f04054 upstream. Maxburst was not set when doing the dma slave configuration. This value is checked by the recently introduced xdmac. It causes an error when doing the slave configuration and so prevents from using dma. Signed-off-by: Ludovic Desroches Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

serial: xilinx: Use platform_get_irq to get irq description structure

2015-05-13T12:14:25Z

commit 5c90c07b98c02198d9777a7c4f3047b0a94bf7ed upstream. For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type = "serial"; property in DT of_serial.c driver maps and unmaps IRQ (because driver probe fails). Then a driver is called but irq mapping is not created that's why driver is failing again in again on request_irq(). Based on this use platform_get_irq() instead of platform_get_resource() which is doing irq_desc allocation and driver itself can request IRQ. Fix both xilinx serial drivers in the tree. Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman

serial: of-serial: Remove device_type = "serial" registration

2015-05-13T12:14:25Z

commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream. Do not probe all serial drivers by of_serial.c which are using device_type = "serial"; property. Only drivers which have valid compatible strings listed in the driver should be probed. When PORT_UNKNOWN is setup probe will fail anyway. Arnd quotation about driver historical background: "when I wrote that driver initially, the idea was that it would get used as a stub to hook up all other serial drivers but after that, the common code learned to create platform devices from DT" This patch fix the problem with on the system with xilinx_uartps and 16550a where of_serial failed to register for xilinx_uartps and because of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking for irq with request_irq() EINVAL is returned. Signed-off-by: Michal Simek Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

serial: 8250: Check UART_SCR is writable

2015-05-06T20:03:59Z

commit f01a0bd8921b9d6668d41fae3198970e6318f532 upstream. Au1x00/RT2800+ doesn't implement the 8250 scratch register (and this may be true of other h/w currently supported by the 8250 driver); read back the canary value written to the scratch register to enable the console h/w restart after resume from system suspend. Fixes: 4516d50aabedb ("serial: 8250: Use canary to restart console ...") Reported-by: Mason Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

serial: imx: Fix clearing of receiver overrun flag

2015-05-06T20:03:59Z

commit 91555ce9012557b2d621d7b0b6ec694218a2a9bc upstream. The writeable bits in the USR2 register are all "write 1 to clear" so only write the bits that actually should be cleared. Fixes: f1f836e4209e ("serial: imx: Add Rx Fifo overrun error message") Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: add support for AMD SOC Carrizo

2015-05-06T20:03:59Z

commit 5ef86b74209db33c133b5f18738dd8f3189b63a1 upstream. Add ACPI identifier for UART on AMD SOC Carrizo. Signed-off-by: Ken Xue Signed-off-by: Greg Kroah-Hartman

tty: serial: fsl_lpuart: clear receive flag on FIFO flush

2015-03-26T22:13:14Z

When the receiver was enabled during startup, a character could have been in the FIFO when the UART get initially used. The driver configures the (receive) watermark level, and flushes the FIFO. However, the receive flag (RDRF) could still be set at that stage (as mentioned in the register description of UARTx_RWFIFO). This leads to an interrupt which won't be handled properly in interrupt mode: The receive interrupt function lpuart_rxint checks the FIFO count, which is 0 at that point (due to the flush during initialization). The problem does not manifest when using DMA to receive characters. Fix this situation by explicitly read the status register, which leads to clearing of the RDRF flag. Due to the flush just after the status flag read, a explicit data read is not to required. Signed-off-by: Stefan Agner Cc: stable Signed-off-by: Greg Kroah-Hartman

tty: serial: fsl_lpuart: specify transmit FIFO size

2015-03-26T22:13:14Z

Specify transmit FIFO size which might be different depending on LPUART instance. This makes sure uart_wait_until_sent in serial core getting called, which in turn waits and checks if the FIFO is really empty on shutdown by using the tx_empty callback. Without the call of this callback, the last several characters might not yet be transmitted when closing the serial port. This can be reproduced by simply using echo and redirect the output to a ttyLP device. Signed-off-by: Stefan Agner Cc: stable Signed-off-by: Greg Kroah-Hartman

serial: samsung: Clear operation mode on UART shutdown

2015-03-26T22:13:14Z

Exynos serial ports operate either in a DMA-based or interrupt-based modes. In DMA-based mode, the UART generates a transfer data request and a Transmission (Tx) interrupt in interrupt-based mode. The Tx IRQ is only unmasked in interrupt-based mode and it was done in s3c24xx_serial_start_tx(). Commit ba019a3e2ad5 ("serial: samsung: remove redundant interrupt enabling") removed the IRQ enable on that function since it is enabled when the mode is set in enable_tx_pio(). The problem is that enable_tx_pio() is only called if the port mode has not been set before but the mode was not cleared on .shutdown(). So if the UART was shutdown and then started up again, the mode set will remain and the Tx IRQ won't be unmasked. This caused a hang on at least Exynos5250, Exynos5420 and Exynos5800 when the system is rebooted or powered off. Fixes: ba019a3e2ad5 ("serial: samsung: remove redundant interrupt enabling") Signed-off-by: Javier Martinez Canillas Reviewed-by: Sylwester Nawrocki Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Fix deadlock in LCR workaround

2015-03-11T15:39:52Z

Trying to write console output from within the serial console driver while the port->lock is held causes recursive deadlock: CPU 0 spin_lock_irqsave(&port->lock) printk() console_unlock() call_console_drivers() serial8250_console_write() spin_lock_irqsave(&port->lock) ** DEADLOCK ** The 8250_dw i/o accessors try to write a console error message if the LCR workaround was unsuccessful. When the port->lock is already held (eg., when called from serial8250_set_termios()), this deadlocks. Make the error message a FIXME until a general solution is devised. Cc: Tim Kryger Reported-by: Zhang Zhen Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman