talos-obmc-linux/drivers/tty, branch dev-4.10

drivers/serial: Add driver for Aspeed virtual UART

2017-07-31T09:28:36+00:00

This change adds a driver for the 16550-based Aspeed virtual UART device. We use a similar process to the of_serial driver for device probe, but expose some VUART-specific functions through sysfs too. The VUART is two UART 'front ends' connected by their FIFO (no actual serial line in between). One is on the BMC side (management controller) and one is on the host CPU side. This driver is for the BMC side. The sysfs files allow the BMC userspace, which owns the system configuration policy, to specify at what IO port and interrupt number the host side will appear to the host on the Host <-> BMC LPC bus. It could be different on a different system (though most of them use 3f8/4). OpenPOWER host firmware doesn't like it when the host-side of the VUART's FIFO is not drained. This driver only disables host TX discard mode when the port is in use. We set the VUART enabled bit when we bind to the device, and clear it on unbind. We don't want to do this on open/release, as the host may be using this bit to configure serial output modes, which is independent of whether the devices has been opened by BMC userspace. Signed-off-by: Jeremy Kerr Signed-off-by: Joel Stanley Acked-by: Rob Herring Reviewed-by: Benjamin Herrenschmidt Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 7fbcf3afe6e8e180bfc39fb3f41657fa6e4af55c) Signed-off-by: Joel Stanley

serial: 8250: Add flag so drivers can avoid THRE probe

2017-07-31T09:28:35+00:00

The probing of THRE irq behaviour assumes the other end will be reading bytes out of the buffer in order to probe the port at driver init. In some cases the other end cannot be relied upon to read these bytes, so provide a flag for them to skip this step. Bit 19 was chosen as the flags are a int and the top bits are taken. Acked-by: Benjamin Herrenschmidt Signed-off-by: Joel Stanley Signed-off-by: Greg Kroah-Hartman (cherry picked from commit ea5244e2af3b4813bf3d90ba6a6481d1a3c33d15) Signed-off-by: Joel Stanley

Revert "drivers/serial: Add driver for Aspeed virtual UART"

2017-07-31T09:14:36+00:00

This reverts commit 969ba225f4bcd109e34ae9d6b40429a32e756ed4.

serial: 8250_of: Add reset support

2017-06-06T06:21:27+00:00

This adds the hooks for an optional reset controller in the 8250 device tree node. Signed-off-by: Joel Stanley Reviewed-by: Philipp Zabel Signed-off-by: Greg Kroah-Hartman (cherry picked from commit e2860e1f62f2e87d268403a749ba1f19663ef19f) Signed-off-by: Joel Stanley

Merge tag 'v4.10.17' into dev-4.10

2017-06-05T02:24:15+00:00

This is the 4.10.17 stable release

tty: pty: Fix ldisc flush after userspace become aware of the data already

2017-05-20T12:31:03+00:00

commit 77dae6134440420bac334581a3ccee94cee1c054 upstream. While using emacs, cat or others' commands in konsole with recent kernels, I have met many times that CTRL-C freeze konsole. After konsole freeze I can't type anything, then I have to open a new one, it is very annoying. See bug report: https://bugs.kde.org/show_bug.cgi?id=175283 The platform in that bug report is Solaris, but now the pty in linux has the same problem or the same behavior as Solaris :) It has high possibility to trigger the problem follow steps below: Note: In my test, BigFile is a text file whose size is bigger than 1G 1:open konsole 1:cat BigFile 2:CTRL-C After some digging, I find out the reason is that commit 1d1d14da12e7 ("pty: Fix buffer flush deadlock") changes the behavior of pty_flush_buffer. Thread A Thread B -------- -------- 1:n_tty_poll return POLLIN 2:CTRL-C trigger pty_flush_buffer tty_buffer_flush n_tty_flush_buffer 3:attempt to check count of chars: ioctl(fd, TIOCINQ, &available) available is equal to 0 4:read(fd, buffer, avaiable) return 0 5:konsole close fd Yes, I know we could use the same patch included in the BUG report as a workaround for linux platform too. But I think the data in ldisc is belong to application of another side, we shouldn't clear it when we want to flush write buffer of this side in pty_flush_buffer. So I think it is better to disable ldisc flush in pty_flush_buffer, because its new hehavior bring no benefit except that it mess up the behavior between POLLIN, and TIOCINQ or FIONREAD. Also I find no flush_buffer function in others' tty driver has the same behavior as current pty_flush_buffer. Fixes: 1d1d14da12e7 ("pty: Fix buffer flush deadlock") Signed-off-by: Wang YanQing Signed-off-by: Greg Kroah-Hartman

serial: omap: suspend device on probe errors

2017-05-20T12:31:03+00:00

commit 77e6fe7fd2b7cba0bf2f2dc8cde51d7b9a35bf74 upstream. Make sure to actually suspend the device before returning after a failed (or deferred) probe. Note that autosuspend must be disabled before runtime pm is disabled in order to balance the usage count due to a negative autosuspend delay as well as to make the final put suspend the device synchronously. Fixes: 388bc2622680 ("omap-serial: Fix the error handling in the omap_serial probe") Cc: Shubhrajyoti D Signed-off-by: Johan Hovold Acked-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman

serial: omap: fix runtime-pm handling on unbind

2017-05-20T12:31:03+00:00

commit 099bd73dc17ed77aa8c98323e043613b6e8f54fc upstream. An unbalanced and misplaced synchronous put was used to suspend the device on driver unbind, something which with a likewise misplaced pm_runtime_disable leads to external aborts when an open port is being removed. Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa024010 ... [] (serial_omap_set_mctrl) from [] (uart_update_mctrl+0x50/0x60) [] (uart_update_mctrl) from [] (uart_shutdown+0xbc/0x138) [] (uart_shutdown) from [] (uart_hangup+0x94/0x190) [] (uart_hangup) from [] (__tty_hangup+0x404/0x41c) [] (__tty_hangup) from [] (tty_vhangup+0x1c/0x20) [] (tty_vhangup) from [] (uart_remove_one_port+0xec/0x260) [] (uart_remove_one_port) from [] (serial_omap_remove+0x40/0x60) [] (serial_omap_remove) from [] (platform_drv_remove+0x34/0x4c) Fix this up by resuming the device before deregistering the port and by suspending and disabling runtime pm only after the port has been removed. Also make sure to disable autosuspend before disabling runtime pm so that the usage count is balanced and device actually suspended before returning. Note that due to a negative autosuspend delay being set in probe, the unbalanced put would actually suspend the device on first driver unbind, while rebinding and again unbinding would result in a negative power.usage_count. Fixes: 7e9c8e7dbf3b ("serial: omap: make sure to suspend device before remove") Cc: Felipe Balbi Cc: Santosh Shilimkar Signed-off-by: Johan Hovold Acked-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman

serial: samsung: Use right device for DMA-mapping calls

2017-05-20T12:31:03+00:00

commit 768d64f491a530062ddad50e016fb27125f8bd7c upstream. Driver should provide its own struct device for all DMA-mapping calls instead of extracting device pointer from DMA engine channel. Although this is harmless from the driver operation perspective on ARM architecture, it is always good to use the DMA mapping API in a proper way. This patch fixes following DMA API debug warning: WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1241 check_sync+0x520/0x9f4 samsung-uart 12c20000.serial: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000006df0f580] [size=64 bytes] Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00137-g07ca963 #51 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x84/0xa0) [] (dump_stack) from [] (__warn+0x14c/0x180) [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50) [] (warn_slowpath_fmt) from [] (check_sync+0x520/0x9f4) [] (check_sync) from [] (debug_dma_sync_single_for_device+0x88/0xc8) [] (debug_dma_sync_single_for_device) from [] (s3c24xx_serial_start_tx_dma+0x100/0x2f8) [] (s3c24xx_serial_start_tx_dma) from [] (s3c24xx_serial_tx_chars+0x198/0x33c) Reported-by: Seung-Woo Kim Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions") Signed-off-by: Marek Szyprowski Reviewed-by: Bartlomiej Zolnierkiewicz Reviewed-by: Krzysztof Kozlowski Reviewed-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

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

2017-05-14T12:08:27+00:00

commit 4e0f5cc65098ea32a1e77baae74215b9bd5276b1 upstream. 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