linux-stable.git/drivers/tty, branch v4.4.123

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

2018-03-18T10:17:53+00:00

commit 9f2068f35729948bde84d87a40d135015911345d upstream.

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

tty/serial: atmel: add new version check for usart

2018-03-18T10:17:53+00:00

commit fd63a8903a2c40425a9811c3371dd4d0f42c0ad3 upstream.

On our at91sam9260 based board the usart0 and usart1 ports report
their versions (ATMEL_US_VERSION) as 0x10302. This version is not
included in the current checks in the driver.

Signed-off-by: Jonas Danielsson 
Acked-by: Richard Genoud 
Acked-by: Nicolas Ferre 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: prevent lockup on full TTY buffers

2018-03-18T10:17:53+00:00

commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream.

When the TTY buffers fill up to the configured maximum, a system lockup
occurs:

[  598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[  598.825796]  0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[  598.832577]  (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[  598.838755] Task dump for CPU 0:
[  598.841977] swapper/0       R  running task        0     0      0 0x00000022
[  598.849023] Call trace:
[  598.851476]  __switch_to+0x98/0xb0
[  598.854870]            (null)

This can be prevented by doing a dummy read of the RX data register.

This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.

Reported-by: Yoshihiro Shimoda 
Signed-off-by: Ulrich Hecht 
Reviewed-by: Geert Uytterhoeven 
Cc: stable 
Tested-by: Nguyen Viet Dung 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_mid: fix broken DMA dependency

2018-02-25T10:03:49+00:00

commit 0ff4230584320b2153752ba54e2e8edbd6addf2c upstream.

In order to enable HSU DMA PCI driver, the HSU DMA Engine
must be enabled. This add a check for that.

Reported-by: kbuild test robot 
Signed-off-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

tty: cyclades: cyz_interrupt is only used for PCI

2018-02-25T10:03:48+00:00

commit 05ead49691d245f67bdd1b30cab5d9af522ac884 upstream.

When CONFIG_PCI is not set, enabling CONFIG_CYZ_INTR has no
practical effect other than generating a warning about an
unused function:

drivers/tty/cyclades.c:1184:20: warning: 'cyz_interrupt' defined but not used [-Wunused-function]
 static irqreturn_t cyz_interrupt(int irq, void *dev_id)

This adds a dependency to avoid that warning.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

tty: hvc_xen: hide xen_console_remove when unused

2018-02-25T10:03:46+00:00

commit e36ae3439936e13c33f5841c7c2c1a9875acbb6d upstream.

xencons_disconnect_backend() is only called from xen_console_remove(),
which is conditionally compiled, so we get a harmless warning when
CONFIG_HVC_XEN_FRONTEND is unset:

hvc/hvc_xen.c:350:12: error: 'xen_console_remove' defined but not used [-Werror=unused-function]

This moves the function down into the same #ifdef section to silence
the warning.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS

2018-02-03T16:04:30+00:00

commit 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 upstream.

The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS
lines, so only allow such wakeup method when the system actually has
RTS/CTS support.

Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD")
Signed-off-by: Fabio Estevam 
Reviewed-by: Martin Kaiser 
Acked-by: Fugang Duan 
Signed-off-by: Greg Kroah-Hartman

sysrq: Fix warning in sysrq generated crash.

2018-01-17T08:35:28+00:00

commit 984cf355aeaa8f2eda3861b50d0e8d3e3f77e83b upstream.

Commit 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq") replaced
spin_lock_irqsave() calls with rcu_read_lock() calls in sysrq. Since
rcu_read_lock() does not disable preemption, faulthandler_disabled() in
__do_page_fault() in x86/fault.c returns false. When the code later calls
might_sleep() in the pagefault handler, we get the following warning:

BUG: sleeping function called from invalid context at ../arch/x86/mm/fault.c:1187
in_atomic(): 0, irqs_disabled(): 0, pid: 4706, name: bash
Preemption disabled at:[] printk+0x48/0x4a

To fix this, we release the RCU read lock before we crash.

Tested this patch on linux 3.18 by booting off one of our boards.

Fixes: 984d74a72076a1 ("sysrq: rcu-ify __handle_sysrq")

Signed-off-by: Ani Sinha 
Reviewed-by: Rik van Riel 
Signed-off-by: Paul E. McKenney 
Signed-off-by: Davidlohr Bueso 
Signed-off-by: Greg Kroah-Hartman

n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

2018-01-02T19:33:28+00:00

commit 966031f340185eddd05affcf72b740549f056348 upstream.

We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit
message:

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa 
Reported-by: syzkaller 
Cc: Jiri Slaby 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

sysrq : fix Show Regs call trace on ARM

2017-12-09T17:42:40+00:00

[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]

When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:

sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[] dump_backtrace+0x0/0x1d0
[] show_stack+0x24/0x30
[] dump_stack+0x90/0xb0
[] check_preemption_disabled+0x100/0x108
[] __this_cpu_preempt_check+0x18/0x20
[] sysrq_handle_showregs+0x1c/0x40
[] __handle_sysrq+0x12c/0x1a0
[] write_sysrq_trigger+0x60/0x70
[] proc_reg_write+0x90/0xd0
[] __vfs_write+0x48/0x90
[] vfs_write+0xa4/0x190
[] SyS_write+0x54/0xb0
[] el0_svc_naked+0x24/0x28

This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.

Signed-off-by: Jibin Xu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman