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

sunsab: Fix detection of BREAK on sunsab serial console

2014-08-14T01:51:50+00:00

[ Upstream commit fe418231b195c205701c0cc550a03f6c9758fd9e ]

Fix detection of BREAK on sunsab serial console: BREAK detection was only
performed when there were also serial characters received simultaneously.
To handle all BREAKs correctly, the check for BREAK and the corresponding
call to uart_handle_break() must also be done if count == 0, therefore
duplicate this code fragment and pull it out of the loop over the received
characters.

Patch applies to 3.16-rc6.

Signed-off-by: Christopher Alexander Tobias Schulze 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

serial: imx: Fix build breakage

2014-07-17T23:23:10+00:00

commit 8bec751bd63847b4044aab8b215db52aa6abde61 upstream.

Fix breakage introduced by
commit c557d392fbf5badd693ea1946a4317c87a26a716,
'serial: Test for no tx data on tx restart'.

Reported-by: Stephen Rothwell 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

serial: Test for no tx data on tx restart

2014-07-17T23:23:08+00:00

commit c557d392fbf5badd693ea1946a4317c87a26a716 upstream.

Commit 717f3bbab3c7628736ef738fdbf3d9a28578c26c,
'serial_core: Fix conditional start_tx on ring buffer not empty'
exposes an incorrect assumption in several drivers' start_tx methods;
the tx ring buffer can, in fact, be empty when restarting tx while
performing flow control.

Affected drivers:
sunsab.c
ip22zilog.c
pmac_zilog.c
sunzilog.c
m32r_sio.c
imx.c

Other in-tree serial drivers either are not affected or already
test for empty tx ring buffer before transmitting.

Test for empty tx ring buffer in start_tx() method, after transmitting
x_char (if applicable).

Reported-by: Aaro Koskinen 
Cc: Seth Bollinger 
Cc: "David S. Miller" 
Cc: Sam Ravnborg 
Cc: Thomas Bogendoerfer 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

serial: Fix IGNBRK handling

2014-07-09T18:21:31+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: Greg Kroah-Hartman

printk/of_serial: fix serial console cessation part way through boot.

2014-07-01T03:13:53+00:00

commit 7fa21dd8bd191564a195291161d6b43db5d9c350 upstream.

Commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
"serial_core: Unregister console in uart_remove_one_port()"
fixed a crash where a serial port was removed but
not deregistered as a console.

There is a side effect of that commit for platforms having serial consoles
and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
is disabled midway through the boot process.

This cessation of the serial console affects PowerPC computers
such as the MVME5100 and SAM440EP.

The sequence is:

	bootconsole [udbg0] enabled
	....
	serial8250/16550 driver initialises and registers its UARTS,
	one of these is the serial console.
	console [ttyS0] enabled
	....
	of_serial probes "platform" devices, registering them as it goes.
	One of these is the serial console.
	console [ttyS0] disabled.

The disabling of the serial console is due to:

	a.  unregister_console in printk not clearing the
	    CONS_ENABLED bit in the console flags,
	    even though it has announced that the console is disabled; and

	b.  of_platform_serial_probe in of_serial not setting the port type
	    before it registers with serial8250_register_8250_port.

This patch ensures that the serial console is re-enabled when of_serial
registers a serial port that corresponds to the designated console.

===
The above failure was identified in Linux-3.15-rc2.

Tested using MVME5100 and SAM440EP PowerPC computers with
kernels built from Linux-3.15-rc5 and tty-next.

The continued operation of the serial console is vital for computers
such as the MVME5100 as that Single Board Computer does not
have any grapical/display hardware.

Signed-off-by: Stephen Chivers 
Tested-by: Stephen Chivers 
Acked-by: Geert Uytterhoeven  [unregister_console]
Signed-off-by: Greg Kroah-Hartman

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

2014-05-03T22:13:05+00:00

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 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial_core: fix uart PORT_UNKNOWN handling

2014-04-24T22:38:22+00:00

While porting a RS485 driver from 2.6.29 to 3.14, i noticed that the serial tty
driver could break it by using uart ports that it does not own :

1. uart_change_pm ist called during uart_open and calls the uart pm function
   without checking for PORT_UNKNOWN.
   The fix is to move uart_change_pm from uart_open to uart_port_startup.
2. The return code from the uart request_port call in uart_set_info is not
   handled properly, leading to the situation that the serial driver also
   thinks it owns the uart ports.
   This can triggered by doing following actions :

   setserial /dev/ttyS0 uart none    # release the uart ports
   modprobe lirc-serial              # or any other device that uses the uart
   setserial /dev/ttyS0 uart 16550   # gives no error and the uart tty driver
                                     # can use the ports as well

Signed-off-by: Thomas Pfaff 
Reviewed-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

serial: samsung: Change barrier() to cpu_relax() in console output

2014-04-24T22:38:22+00:00

The two functions to write out to the console (one used in normal
console mode and one in polling console mode) were slightly different.
One used a barrier() in its loop and the other a cpu_relax().  The
barrier() really doesn't do anything since we're using rd_regl() to
read the port anyway.  Switch it to cpu_relax() to make things
consistent.

No known bugs / issues are fixed by this change--it just makes things
more consistent.

Signed-off-by: Doug Anderson 
Signed-off-by: Greg Kroah-Hartman

serial: samsung: don't check config for every character

2014-04-24T22:38:21+00:00

The s3c24xx_serial_console_putchar() is _only_ ever used by
s3c24xx_serial_console_write() and is called in a loop (indirectly
through uart_console_write()).  There's no reason to call
s3c24xx_port_configured() for every iteration through the loop.  Move
it outside the loop.

Signed-off-by: Doug Anderson 
Signed-off-by: Greg Kroah-Hartman

serial: samsung: Use the passed in "port", fixing kgdb w/ no console

2014-04-24T22:38:21+00:00

The two functions in the samsung serial driver used for writing
characters out to the port were inconsistent about whether they used
the passed in "port" or the global "cons_uart".  There was no reason
to use the global and the use of the global in
s3c24xx_serial_put_poll_char() caused a crash in the case where you
used the serial port for kgdboc but not for console.

Fix it so we used the passed in variable.

Note that this doesn't fix all problems with the samsung serial
driver.  Specifically:
* s3c24xx_serial_console_putchar() is still 99% identical to
  s3c24xx_serial_put_poll_char() (the function signature is different,
  but that's about it).  A future patch will make them slightly less
  identical and judging by other serial drivers we may need yet more
  differences eventually.
* The samsung serial driver still doesn't allow you to have more than
  one console port since it still uses the global cons_uart in
  s3c24xx_serial_console_write().

Signed-off-by: Doug Anderson 
Signed-off-by: Greg Kroah-Hartman