BMC/Intel-BMC/linux.git/drivers/tty/serial, branch dev-4.3

serial/aspeed-vuart: Perform enable/disable on driver bind/unbind

2016-02-12T04:38:57+00:00

Rather than exposing an enable sysfs attribute, we can just 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

serial/aspeed-vuart: Only disable host tx discard when serial port is in use

2016-02-12T04:15:21+00:00

OpenPOWER firmware doesn't like it when the host-side of the VUART's FIFO is not drained. This change only disables host TX discard mode when the port has been opened. Signed-off-by: Jeremy Kerr Tested-by: Norman James Signed-off-by: Joel Stanley

serial/aspeed-vuart: Fix typo

2016-02-10T06:22:03+00:00

Signed-off-by: Joel Stanley

serial/aspeed-vuart: Disable host TX discard mode during init

2016-02-10T06:20:56+00:00

If host TX discard mode is enabled, we don't see the LSR[RBR} bit getting set on new characters written on the host side. This makes the VUART a little useless. This change set this bit during VUART initialisation, to disable host TX discard. Signed-off-by: Jeremy Kerr Signed-off-by: Joel Stanley

drivers/serial: Add driver for Aspeed virtual UART

2016-01-30T00:34:18+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. Signed-off-by: Jeremy Kerr

Revert "serial: 8250_dma: don't bother DMA with small transfers"

2015-10-18T04:24:46+00:00

This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb. This commit prevents from sending "big" file using Bluetooth. When sending a lot of data quickly through the Bluetooth interface, and after a variable amount of data sent, transfer fails with error: kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00 Found on T100TA. After reverting this commit, send works fine for any file size. Signed-off-by: Frederic Danis Fixes: 9119fba0cfed (serial: 8250_dma: don't bother DMA with small transfers) Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Acked-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

serial: 8250: add uart_config entry for PORT_RT2880

2015-10-04T18:16:12+00:00

This adds an entry to the uart_config table for PORT_RT2880 enabling rx/tx FIFOs. The UART is actually a Palmchip BK-3103 which is found in several devices from Alchemy/RMI, Ralink, and Sigma Designs. Signed-off-by: Mans Rullgard Cc: stable Signed-off-by: Greg Kroah-Hartman

serial: atmel: fix error path of probe function

2015-10-04T17:51:42+00:00

If atmel_init_gpios fails the port has already been marked as busy (in line 2629), so this must be undone in the error path. This bug was introduced because I created the patch that finally became 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails") on top of 3.19 which didn't have commit 6fbb9bdf0f3f ("tty/serial: at91: fix error handling in atmel_serial_probe()") yet. Signed-off-by: Uwe Kleine-König Fixes: 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails") Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

Revert "serial: imx: remove unbalanced clk_prepare"

2015-10-04T17:51:42+00:00

This reverts commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d. Commit ("9e7b399d6528ea") causes the following warning and sometimes also hangs the system: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:868 mutex_trylock+0x20c/0x22c() DEBUG_LOCKS_WARN_ON(in_interrupt()) Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-next-20150818-00001-g14418a6 #4 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<80012f08>] (dump_backtrace) from [<800130a4>] (show_stack+0x18/0x1c) r6:00000364 r5:00000000 r4:00000000 r3:00000000 [<8001308c>] (show_stack) from [<807902b8>] (dump_stack+0x88/0xa4) [<80790230>] (dump_stack) from [<8002a604>] (warn_slowpath_common+0x80/0xbc) r5:807945c4 r4:80ab3b50 [<8002a584>] (warn_slowpath_common) from [<8002a6e4>] (warn_slowpath_fmt+0x38/0x40) r8:00000000 r7:8131100c r6:8054c3cc r5:8131300c r4:80b0a570 [<8002a6b0>] (warn_slowpath_fmt) from [<807945c4>] (mutex_trylock+0x20c/0x22c) r3:8095d0d8 r2:8095ab28 [<807943b8>] (mutex_trylock) from [<8054c3cc>] (clk_prepare_lock+0x14/0xf4) r7:8131100c r6:be3f0c80 r5:00000037 r4:be3f0c80 [<8054c3b8>] (clk_prepare_lock) from [<8054dbfc>] (clk_prepare+0x18/0x30) r5:00000037 r4:be3f0c80 [<8054dbe4>] (clk_prepare) from [<8036a600>] (imx_console_write+0x30/0x244) r4:812d0bc8 r3:8132b9a4 To reproduce the problem we only need to let the board idle for something like 30 seconds. Tested on a imx6q-sabresd. Signed-off-by: Fabio Estevam Reviewed-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman

tty: serial: Add missing module license for 8250_base.ko

2015-09-22T16:09:15+00:00

The split of the 8250 driver into a 8250_base/8250.ko resulted in a lack of a license for the 8250_base.ko module. This caused the module to fail to load and the kernel to be tainted. Add the appropriate MODULE_LICENSE to 8250_port.c, which is always compiled into 8250_base.ko Signed-off-by: Jonathan McDowell Reported-by: Mikael Pettersson Signed-off-by: Greg Kroah-Hartman