linux-toradex.git/drivers/tty/serial, branch v3.12.25

serial: Fix IGNBRK handling

2014-07-18T13:51:09+00:00

commit ef8b9ddcb45fa3b1e11acd72be2398001e807d14 upstream.

If IGNBRK is set without either BRKINT or PARMRK set, some uart
drivers send a 0x00 byte for BREAK without the TTYBREAK flag to the
line discipline, when it should send either nothing or the TTYBREAK flag
set. This happens because the read_status_mask masks out the BI
condition, which uart_insert_char() then interprets as a normal 0x00 byte.

SUS v3 is clear regarding the meaning of IGNBRK; Section 11.2.2, General
Terminal Interface - Input Modes, states:
  "If IGNBRK is set, a break condition detected on input shall be ignored;
   that is, not put on the input queue and therefore not read by any
   process."

Fix read_status_mask to include the BI bit if IGNBRK is set; the
lsr status retains the BI bit if a BREAK is recv'd, which is
subsequently ignored in uart_insert_char() when masked with the
ignore_status_mask.

Affected drivers:
8250 - all
serial_txx9
mfd
amba-pl010
amba-pl011
atmel_serial
bfin_uart
dz
ip22zilog
max310x
mxs-auart
netx-serial
pnx8xxx_uart
pxa
sb1250-duart
sccnxp
serial_ks8695
sirfsoc_uart
st-asc
vr41xx_siu
zs
sunzilog
fsl_lpuart
sunsab
ucc_uart
bcm63xx_uart
sunsu
efm32-uart
pmac_zilog
mpsc
msm_serial
m32r_sio

Unaffected drivers:
omap-serial
rp2
sa1100
imx
icom

Annotated for fixes:
altera_uart
mcf

Drivers without break detection:
21285
xilinx-uartps
altera_jtaguart
apbuart
arc-uart
clps711x
max3100
uartlite
msm_serial_hs
nwpserial
lantiq
vt8500_serial

Unknown:
samsung
mpc52xx_uart
bfin_sport_uart
cpm_uart/core

Fixes: Bugzilla #71651, '8250_core.c incorrectly handles IGNBRK flag'
Reported-by: Ivan 
Signed-off-by: Peter Hurley 
Signed-off-by: Jiri Slaby

serial: 8250_dw: Fix LCR workaround regression

2014-07-02T10:05:41+00:00

commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream.

Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround)
caused a regression. It added a check that the LCR was written properly
to detect and workaround the busy quirk, but the behaviour of bit 5
(UART_LCR_SPAR) differs between IP versions 3.00a and 3.14c per the
docs. On older versions this caused the check to fail and it would
repeatedly force idle and rewrite the LCR register, causing delays and
preventing any input from serial being received.

This is fixed by masking out UART_LCR_SPAR before making the comparison.

Signed-off-by: James Hogan 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Tim Kryger 
Cc: Ezequiel Garcia 
Cc: Matt Porter 
Cc: Markus Mayer 
Tested-by: Tim Kryger 
Tested-by: Ezequiel Garcia 
Tested-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

serial: 8250_dw: Improve unwritable LCR workaround

2014-07-02T10:05:41+00:00

commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream.

When configured with UART_16550_COMPATIBLE=NO or in versions prior to
the introduction of this option, the Designware UART will ignore writes
to the LCR if the UART is busy.  The current workaround saves a copy of
the last written LCR and re-writes it in the ISR for a special interrupt
that is raised when a write was ignored.

Unfortunately, interrupts are typically disabled prior to performing a
sequence of register writes that include the LCR so the point at which
the retry occurs is too late.  An example is serial8250_do_set_termios()
where an ignored LCR write results in the baud divisor not being set and
instead a garbage character is sent out the transmitter.

Furthermore, since serial_port_out() offers no way to indicate failure,
a serious effort must be made to ensure that the LCR is actually updated
before returning back to the caller.  This is difficult, however, as a
UART that was busy during the first attempt is likely to still be busy
when a subsequent attempt is made unless some extra action is taken.

This updated workaround reads back the LCR after each write to confirm
that the new value was accepted by the hardware.  Should the hardware
ignore a write, the TX/RX FIFOs are cleared and the receive buffer read
before attempting to rewrite the LCR out of the hope that doing so will
force the UART into an idle state.  While this may seem unnecessarily
aggressive, writes to the LCR are used to change the baud rate, parity,
stop bit, or data length so the data that may be lost is likely not
important.  Admittedly, this is far from ideal but it seems to be the
best that can be done given the hardware limitations.

Lastly, the revised workaround doesn't touch the LCR in the ISR, so it
avoids the possibility of a "serial8250: too much work for irq" lock up.
This problem is rare in real situations but can be reproduced easily by
wiring up two UARTs and running the following commands.

  # stty -F /dev/ttyS1 echo
  # stty -F /dev/ttyS2 echo
  # cat /dev/ttyS1 &
  [1] 375
  # echo asdf > /dev/ttyS1
  asdf

  [   27.700000] serial8250: too much work for irq96
  [   27.700000] serial8250: too much work for irq96
  [   27.710000] serial8250: too much work for irq96
  [   27.710000] serial8250: too much work for irq96
  [   27.720000] serial8250: too much work for irq96
  [   27.720000] serial8250: too much work for irq96
  [   27.730000] serial8250: too much work for irq96
  [   27.730000] serial8250: too much work for irq96
  [   27.740000] serial8250: too much work for irq96

Signed-off-by: Tim Kryger 
Reviewed-by: Matt Porter 
Reviewed-by: Markus Mayer 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby 

Conflicts:
	drivers/tty/serial/8250/8250_dw.c

8250_core: Fix unwanted TX chars write

2014-06-06T09:40:21+00:00

commit b08c9c317e3f7764a91d522cd031639ba42b98cc upstream.

On transmit-hold-register empty, serial8250_tx_chars
should be called only if we don't use DMA.
DMA has its own tx cycle.

Signed-off-by: Loic Poulain 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Jiri Slaby

serial: 8250: Fix thread unsafe __dma_tx_complete function

2014-06-06T09:40:21+00:00

commit f8fd1b0350d3a4581125f5eda6528f5a2c5f9183 upstream.

__dma_tx_complete is not protected against concurrent
call of serial8250_tx_dma. it can lead to circular tail
index corruption or parallel call of serial_tx_dma on the
same data portion.

This patch fixes this issue by holding the port lock.

Signed-off-by: Loic Poulain 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Jiri Slaby

tty: serial: 8250_core.c Bug fix for Exar chips.

2014-05-15T07:55:46+00:00

commit b790f210fe8423eff881b2a8a93ba5dbc45534d0 upstream.

The sleep function was updated to put the serial port to sleep only when necessary.
This appears to resolve the errant behavior of the driver as described in
Kernel Bug 61961 – "My Exar Corp. XR17C/D152 Dual PCI UART modem does not
work with 3.8.0".

Signed-off-by: Michael Welling 
Signed-off-by: Jiri Slaby

serial: sirf: fix kernel panic caused by unpaired spinlock

2014-02-22T21:32:26+00:00

commit fb78b811422cd2d8c8605949cc4cc13618347ad5 upstream.

commit 8b9ade9f74f8a279 coming from Viresh Kumar "tty: serial: sirfsoc: drop
uart_port->lock before calling tty_flip_buffer_push()" broke sirfsoc uart
driver by knic:

	[    5.129122] BUG: spinlock already unlocked on CPU#0, ip6tables/1331
	[    5.132554]  lock: sirfsoc_uart_ports+0x4/0x8a0, .magic: dead4ead,
	.owner: /-1, .owner_cpu: -1
	[    5.141651] CPU: 0 PID: 1331 Comm: ip6tables Tainted: G
	W  O 3.10.16 #3
	[    5.148866] [] (unwind_backtrace+0x0/0xe0) from
	[] (show_stack+0x10/0x14)
	[    5.157362] [] (show_stack+0x10/0x14) from
	[] (do_raw_spin_unlock+0x40/0xc8)
	[    5.166125] [] (do_raw_spin_unlock+0x40/0xc8) from
	[] (_raw_spin_unlock+0x8/0x40)
	[    5.175322] [] (_raw_spin_unlock+0x8/0x40) from
	[] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0)
	[    5.185120] []
	(sirfsoc_uart_pio_rx_chars+0xa4/0xc0) from []
	(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0)
	[    5.195875] []
	(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) from []
	(tasklet_action+0x8c/0xec)
	[    5.205673] [] (tasklet_action+0x8c/0xec) from
	[] (__do_softirq+0xec/0x1d4)
	[    5.214347] [] (__do_softirq+0xec/0x1d4) from
	[] (do_softirq+0x48/0x54)
	[    5.222674] [] (do_softirq+0x48/0x54) from
	[] (irq_exit+0x74/0xc0)
	[    5.230573] [] (irq_exit+0x74/0xc0) from
	[] (handle_IRQ+0x6c/0x90)
	[    5.238465] [] (handle_IRQ+0x6c/0x90) from
	[] (__irq_svc+0x40/0x70)
	[    5.246446] [] (__irq_svc+0x40/0x70) from
	[] (mark_page_accessed+0xc/0x68)
	[    5.255034] [] (mark_page_accessed+0xc/0x68) from
	[] (unmap_single_vma+0x3bc/0x550)
	[    5.264402] [] (unmap_single_vma+0x3bc/0x550) from
	[] (unmap_vmas+0x44/0x54)
	[    5.273164] [] (unmap_vmas+0x44/0x54) from
	[] (exit_mmap+0xc4/0x1e0)
	[    5.281233] [] (exit_mmap+0xc4/0x1e0) from
	[] (mmput+0x3c/0xdc)
	[    5.288868] [] (mmput+0x3c/0xdc) from []
	(do_exit+0x30c/0x828)
	[    5.296413] [] (do_exit+0x30c/0x828) from
	[] (do_group_exit+0x4c/0xb0)
	[    5.304653] [] (do_group_exit+0x4c/0xb0) from
	[] (__wake_up_parent+0x0/0x18)

Root cause:
the commit dropped uart_port->lock before calling tty_flip_buffer_push(), but in sirfsoc-uart,
sirfsoc_uart_pio_rx_chars() can be called by sirfsoc_rx_tmo_process_tl(). here uart_port->lock
has not been taken yet. so that caused unpaired lock/unlock.

Solution:
This patch is doing a quick fix for that, it adds spin_lock/unlock(&port->lock) protect to
sirfsoc_uart_pio_rx_chars() in sirfsoc_rx_tmo_process_tl() to keep spin_lock/unlock in pair.

Signed-off-by: Qipan Li 
Signed-off-by: Barry Song 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: enable UART_BUG_NOMSR for Tegra

2014-02-06T19:22:17+00:00

commit 3685f19e07802ec4207b52465c408f185b66490e upstream.

Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
their MODEM-control signals tied off to a static state. However UARTs A
and B can optionally route those signals to/from package pins, depending
on the exact pinmux configuration.

When these signals are not routed to package pins, false interrupts may
trigger either temporarily, or permanently, all while not showing up in
the IIR; it will read as NO_INT. This will eventually lead to the UART
IRQ being disabled due to unhandled interrupts. When this happens, the
kernel may print e.g.:

    irq 68: nobody cared (try booting with the "irqpoll" option)

In order to prevent this, enable UART_BUG_NOMSR. This prevents
UART_IER_MSI from being enabled, which prevents the false interrupts
from triggering.

In practice, this is not needed under any of the following conditions:

* On Tegra chips after Tegra30, since the HW bug has apparently been
  fixed.

* On UARTs C..E since their MODEM control signals are tied to the correct
  static state which doesn't trigger the issue.

* On UARTs A..B if the MODEM control signals are routed out to package
  pins, since they will then carry valid signals.

However, we ignore these exceptions for now, since they are only relevant
if a board actually hooks up more than a 4-wire UART, and no currently
supported board does this. If we ever support a board that does, we can
refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
into account, and/or read a flag from DT/... that indicates that the
board has hooked up and pinmux'd more than a 4-wire UART.

Reported-by: Olof Johansson  # autotester
Signed-off-by: Stephen Warren 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix initialisation of Quatech cards with the AMCC PCI chip

2014-02-06T19:22:17+00:00

commit 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream.

Fix the initialisation of older Quatech serial cards which are fitted with
the AMCC PCI Matchmaker interface chip.

Signed-off-by: Jonathan Woithe (jwoithe@just42.net)
Signed-off-by: Greg Kroah-Hartman

serial: add support for 200 v3 series Titan card

2014-02-06T19:22:17+00:00

commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream.

Signed-off-by: Yegor Yefremov 
Signed-off-by: Greg Kroah-Hartman