linux-stable.git/drivers/tty, branch v3.16.46

serial: mxs-auart: Fix baudrate calculation

2017-07-18T17:40:27+00:00

commit a6040bc610554c66088fda3608ae5d6307c548e4 upstream.

The reference manual for the i.MX28 recommends to calculate the divisor
as

	divisor = (UARTCLK * 32) / baud rate, rounded to the nearest integer

, so let's do this. For a typical setup of UARTCLK = 24 MHz and baud
rate = 115200 this changes the divisor from 6666 to 6667 and so the
actual baud rate improves from 115211.521 Bd (error ≅ 0.01 %) to
115194.240 Bd (error ≅ 0.005 %).

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context, indentation]
Signed-off-by: Ben Hutchings

serial: mxs-auart: fix baud rate range

2017-07-18T17:40:27+00:00

commit df57cf6a879502cd6e5559c1f2d6db12128e074f upstream.

Currently mxs-auart doesn't care correctly about the baud rate divisor.
According to reference manual the baud rate divisor must be between
0x000000EC and 0x003FFFC0. So calculate the possible baud rate range
and use it for uart_get_baud_rate().

Signed-off-by: Stefan Wahren 
Reviewed-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

serial: exar: Fix initialization of EXAR registers for ports > 0

2017-06-05T20:17:06+00:00

commit 5b5f252d67afd7bd5b923c664206d60800bf5054 upstream.

So far, pci_xr17v35x_setup always initialized 8XMODE, FCTR & Co. for
port 0 because it used the address of that port instead of moving the
pointer according to the port number. Fix this and remove the unneeded
temporary ioremap by moving default_setup up and reusing the membase it
fills into the port structure.

Fixes: 14faa8cce88e ("tty/8250 Add support for Commtech's Fastcom Async-335 and Fastcom Async-PCIe cards")
Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16:
 - Adjust filename, context
 - Add 'ret' variable]
Signed-off-by: Ben Hutchings

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

2017-06-05T20:17:03+00:00

commit 1c9c858e2ff8ae8024a3d75d2ed080063af43754 upstream.

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 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tty: serial: msm: Fix module autoload

2017-06-05T20:16:50+00:00

commit abe81f3b8ed2996e1712d26d38ff6b73f582c616 upstream.

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/tty/serial/msm_serial.ko | grep alias
$

After this patch:

$ modinfo drivers/tty/serial/msm_serial.ko | grep alias
alias:          of:N*T*Cqcom,msm-uartdmC*
alias:          of:N*T*Cqcom,msm-uartdm
alias:          of:N*T*Cqcom,msm-uartC*
alias:          of:N*T*Cqcom,msm-uart

Signed-off-by: Javier Martinez Canillas 
Acked-by: Bjorn Andersson 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

serial: samsung: Use %pa to print 'resource_size_t' type

2017-04-04T21:21:55+00:00

commit 1ff5b64dccbf23acfe7993b9132b6992922a4756 upstream.

When building multi_v7_defconfig with CONFIG_ARM_LPAE=y the following warning
is seen:

drivers/tty/serial/samsung.c: In function 's3c24xx_serial_init_port':
drivers/tty/serial/samsung.c:1229:2: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'resource_size_t' [-Wformat]

Use %pa to print 'resource_size_t' type to fix the warning.

Reported-by: Olof's autobuilder 
Signed-off-by: Fabio Estevam 
Reviewed-by: Jingoo Han 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
Cc: Arnd Bergmann

tty: n_hdlc: get rid of racy n_hdlc.tbuf

2017-03-16T02:27:27+00:00

commit 82f2341c94d270421f383641b7cd670e474db56b upstream.

Currently N_HDLC line discipline uses a self-made singly linked list for
data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
an error.

The commit be10eb7589337e5defbe214dae038a53dd21add8
("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
one data buffer to tx_free_buf_list twice. That causes double free in
n_hdlc_release().

Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
in case of tx error put current data buffer after the head of tx_buf_list.

Signed-off-by: Alexander Popov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

TTY: n_hdlc, fix lockdep false positive

2017-03-16T02:27:27+00:00

commit e9b736d88af1a143530565929390cadf036dc799 upstream.

The class of 4 n_hdls buf locks is the same because a single function
n_hdlc_buf_list_init is used to init all the locks. But since
flush_tx_queue takes n_hdlc->tx_buf_list.spinlock and then calls
n_hdlc_buf_put which takes n_hdlc->tx_free_buf_list.spinlock, lockdep
emits a warning:
=============================================
[ INFO: possible recursive locking detected ]
4.3.0-25.g91e30a7-default #1 Not tainted
---------------------------------------------
a.out/1248 is trying to acquire lock:
 (&(&list->spinlock)->rlock){......}, at: [] n_hdlc_buf_put+0x20/0x60 [n_hdlc]

but task is already holding lock:
 (&(&list->spinlock)->rlock){......}, at: [] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&list->spinlock)->rlock);
  lock(&(&list->spinlock)->rlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by a.out/1248:
 #0:  (&tty->ldisc_sem){++++++}, at: [] tty_ldisc_ref_wait+0x20/0x50
 #1:  (&(&list->spinlock)->rlock){......}, at: [] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
...
Call Trace:
...
 [] _raw_spin_lock_irqsave+0x50/0x70
 [] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
 [] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc]
 [] tty_ioctl+0x3f1/0xe40
...

Fix it by initializing the spin_locks separately. This removes also
reduntand memset of a freshly kzallocated space.

Signed-off-by: Jiri Slaby 
Reported-by: Dmitry Vyukov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

sysrq: attach sysrq handler correctly for 32-bit kernel

2017-03-16T02:26:56+00:00

commit 802c03881f29844af0252b6e22be5d2f65f93fd0 upstream.

The sysrq input handler should be attached to the input device which has
a left alt key.

On 32-bit kernels, some input devices which has a left alt key cannot
attach sysrq handler.  Because the keybit bitmap in struct input_device_id
for sysrq is not correctly initialized.  KEY_LEFTALT is 56 which is
greater than BITS_PER_LONG on 32-bit kernels.

I found this problem when using a matrix keypad device which defines
a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32).

Cc: Jiri Slaby 
Signed-off-by: Akinobu Mita 
Acked-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done

2017-03-16T02:26:56+00:00

commit b389f173aaa1204d6dc1f299082a162eb0491545 upstream.

When using RS485 in half duplex, RX should be enabled when TX is
finished, and stopped when TX starts.

Before commit 0058f0871efe7b01c6 ("tty/serial: atmel: fix RS485 half
duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA
was used. So, collisions could happened.

But disabling RX in atmel_start_tx() uncovered another bug:
RX was enabled again in the wrong place (in atmel_tx_dma) instead of
being enabled when TX is finished (in atmel_complete_tx_dma), so the
transmission simply stopped.

This bug was not triggered before commit 0058f0871efe7b01c6
("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was
never disabled before.

Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem.

Reported-by: Gil Weber 
Fixes: 0058f0871efe7b01c6
Tested-by: Gil Weber 
Signed-off-by: Richard Genoud 
Acked-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16:
 - s/port->rs485/atmel_port->rs485/
 - Adjust context]
Signed-off-by: Ben Hutchings