kernel/drivers/tty/serial/8250, branch linux-4.1.y

serial: 8250: omap: Disable DMA for console UART

2018-05-23T01:36:24Z

[ Upstream commit 84b40e3b57eef1417479c00490dd4c9f6e5ffdbc ] Kernel always writes log messages to console via serial8250_console_write()->serial8250_console_putchar() which directly accesses UART_TX register _without_ using DMA. But, if other processes like systemd using same UART port, then these writes are handled by a different code flow using 8250_omap driver where there is provision to use DMA. It seems that it is possible that both DMA and CPU might simultaneously put data to UART FIFO and lead to potential loss of data due to FIFO overflow and weird data corruption. This happens when both kernel console and userspace tries to write simultaneously to the same UART port. Therefore, disable DMA on kernel console port to avoid potential race between CPU and DMA. Signed-off-by: Vignesh R Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Add Brainboxes UC-260 4 port serial device

2018-03-21T03:49:54Z

[ Upstream commit 9f2068f35729948bde84d87a40d135015911345d ] Add PCI ids for two variants of Brainboxes UC-260 quad port PCI serial cards. Suggested-by: Andy Shevchenko Signed-off-by: Nikola Ciprich Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()

2018-01-17T17:55:17Z

[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ] This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means the user has passed in invalid data with the TIOCSRS485 ioctl() since RTS must have a different polarity when sending and when not sending. In this case, rs485 mode is not enabled (the RS485_URA bit is not set in the RS485 Enable Register) and this is supposed to be signaled back to the user by clearing the SER_RS485_ENABLED bit in struct serial_rs485 ... except a missing tilde character is preventing that from happening. Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART") Cc: Ricardo Ribalda Delgado Cc: "Ji-Ze Hong (Peter Hong)" Signed-off-by: Lukas Wunner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Add Amazon PCI serial device ID

2018-01-17T17:55:17Z

[ Upstream commit 3bfd1300abfe3adb18e84a89d97a0e82a22124bb ] This device will be used in future Amazon EC2 instances as the primary serial port (i.e., data sent to this port will be available via the GetConsoleOuput [1] EC2 API). [1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.html Cc: stable Signed-off-by: Matt Wilson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

8250_pci: Fix potential use-after-free in error path

2018-01-17T17:55:16Z

[ Upstream commit c130b666a9a711f985a0a44b58699ebe14bb7245 ] Commit f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during PCI error recovery") introduces a potential use-after-free in case the pciserial_init_ports call in serial8250_io_resume fails, which may happen if a memory allocation fails or if the .init quirk failed for whatever reason). If this happen, further pci_get_drvdata will return a pointer to freed memory. This patch reworks the PCI recovery resume hook to restore the old priv structure in this case, which should be ok, since the ports were already detached. Such error during recovery causes us to give up on the recovery. Fixes: f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during PCI error recovery") Reported-by: Michal Suchanek Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Guilherme G. Piccoli Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Detach low-level driver during PCI error recovery

2018-01-17T17:31:54Z

[ Upstream commit f209fa03fc9d131b3108c2e4936181eabab87416 ] During a PCI error recovery, like the ones provoked by EEH in the ppc64 platform, all IO to the device must be blocked while the recovery is completed. Current 8250_pci implementation only suspends the port instead of detaching it, which doesn't prevent incoming accesses like TIOCMGET and TIOCMSET calls from reaching the device. Those end up racing with the EEH recovery, crashing it. Similar races were also observed when opening the device and when shutting it down during recovery. This patch implements a more robust IO blockage for the 8250_pci recovery by unregistering the port at the beginning of the procedure and re-adding it afterwards. Since the port is detached from the uart layer, we can be sure that no request will make through to the device during recovery. This is similar to the solution used by the JSM serial driver. I thank Peter Hurley for valuable input on this one over one year ago. Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_omap: Fix probe and remove for PM runtime

2017-06-13T13:29:20Z

[ Upstream commit 4e0f5cc65098ea32a1e77baae74215b9bd5276b1 ] Otherwise the interconnect related code implementing PM runtime will produce these errors on a failed probe: omap_uart 48066000.serial: omap_device: omap_device_enable() called from invalid state 1 omap_uart 48066000.serial: use pm_runtime_put_sync_suspend() in driver? Note that we now also need to check for priv in omap8250_runtime_suspend() as it has not yet been registered if probe fails. And we need to use pm_runtime_put_sync() to properly idle the device like we already do in omap8250_remove(). Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cards

2017-05-17T19:06:58Z

[ Upstream commit 1c9c858e2ff8ae8024a3d75d2ed080063af43754 ] The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports, respectively. The first 4 ports are implemented by an OX16PCI954 chip, and the second 4 ports are implemented by an OX16C954 chip on a local bus, bridged by the second PCI function of the OX16PCI954. The ports are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a non-standard oscillator frequency of 20 MHz (base_baud = 1250000). Signed-off-by: Ian Abbott Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250: added acces i/o products quad and octal serial cards

2016-09-15T22:53:30Z

[ Upstream commit c8d192428f52f244130b84650ad616df09f2b1e1 ] Added devices ids for acces i/o products quad and octal serial cards that make use of existing Pericom PI7C9X7954 and PI7C9X7958 configurations . Signed-off-by: Jimi Damon Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

8250: use callbacks to access UART_DLL/UART_DLM

2016-07-11T03:06:55Z

[ Upstream commit 0b41ce991052022c030fd868e03877700220b090 ] Some UART HW has a single register combining UART_DLL/UART_DLM (this was probably forgotten in the change that introduced the callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9) Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...") Signed-off-by: Sebastian Frias Reviewed-by: Peter Hurley Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin