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

serial: imx: Fix DMA handling for IDLE condition aborts

2015-06-23T00:01:23+00:00

commit 392bceedb107a3dc1d4287e63d7670d08f702feb upstream.

The driver configures the IDLE condition to interrupt the SDMA engine.
Since the SDMA UART ROM script doesn't clear the IDLE bit itself, this
caused repeated 1-byte DMA transfers, regardless of available data in the
RX FIFO. Also, when returning due to the IDLE condition, the UART ROM
script already increased its counter, causing residue to be off by one.

This patch clears the IDLE condition to avoid repeated 1-byte DMA transfers
and decreases count by when the DMA transfer was aborted due to the IDLE
condition, fixing serial transfers using DMA on i.MX6Q.

Reported-by: Peter Seiderer 
Signed-off-by: Philipp Zabel 
Tested-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman

tty/serial: at91: maxburst was missing for dma transfers

2015-05-13T12:16:57+00:00

commit a8d4e01637902311c5643b69a5c80e2805f04054 upstream.

Maxburst was not set when doing the dma slave configuration. This value
is checked by the recently introduced xdmac. It causes an error when
doing the slave configuration and so prevents from using dma.

Signed-off-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

serial: of-serial: Remove device_type = "serial" registration

2015-05-13T12:16:56+00:00

commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream.

Do not probe all serial drivers by of_serial.c which are using
device_type = "serial"; property. Only drivers which have valid
compatible strings listed in the driver should be probed.

When PORT_UNKNOWN is setup probe will fail anyway.

Arnd quotation about driver historical background:
"when I wrote that driver initially, the idea was that it would
get used as a stub to hook up all other serial drivers but after
that, the common code learned to create platform devices from DT"

This patch fix the problem with on the system with xilinx_uartps and
16550a where of_serial failed to register for xilinx_uartps and because
of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
for irq with request_irq() EINVAL is returned.

Signed-off-by: Michal Simek 
Acked-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

tty: serial: fsl_lpuart: clear receive flag on FIFO flush

2015-04-19T08:11:08+00:00

commit 8e4934c6d6c659e22b1b746af4196683e77ce6ca upstream.

When the receiver was enabled during startup, a character could
have been in the FIFO when the UART get initially used. The
driver configures the (receive) watermark level, and flushes the
FIFO. However, the receive flag (RDRF) could still be set at that
stage (as mentioned in the register description of UARTx_RWFIFO).
This leads to an interrupt which won't be handled properly in
interrupt mode: The receive interrupt function lpuart_rxint checks
the FIFO count, which is 0 at that point (due to the flush
during initialization). The problem does not manifest when using
DMA to receive characters.

Fix this situation by explicitly read the status register, which
leads to clearing of the RDRF flag. Due to the flush just after
the status flag read, a explicit data read is not to required.

Signed-off-by: Stefan Agner 
Signed-off-by: Greg Kroah-Hartman

Change email address for 8250_pci

2015-03-26T14:06:53+00:00

commit f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 upstream.

I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.

Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

tty/serial: at91: fix error handling in atmel_serial_probe()

2015-03-06T22:43:30+00:00

commit 6fbb9bdf0f3fbe23aeff806489791aa876adaffb upstream.

-EDEFER error wasn't handle properly by atmel_serial_probe().
As an example, when atmel_serial_probe() is called for the first time, we pass
the test_and_set_bit() test to check whether the port has already been
initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly
returned before by clk_get(). Consequently atmel_serial_probe() used to return
this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask.
When atmel_serial_probe() was called for the second time, it used to fail on
the test_and_set_bit() function then returning -EBUSY.

When atmel_serial_probe() fails, this patch make it clear the port bit in the
"atmel_ports_in_use" mask, if needed, before returning the error code.

Signed-off-by: Cyrille Pitchen 
Acked-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

serial: samsung: wait for transfer completion before clock disable

2015-01-16T14:59:32+00:00

commit 1ff383a4c3eda8893ec61b02831826e1b1f46b41 upstream.

This patch adds waiting until transmit buffer and shifter will be empty
before clock disabling.

Without this fix it's possible to have clock disabled while data was
not transmited yet, which causes unproper state of TX line and problems
in following data transfers.

Signed-off-by: Robert Baldyga 
Signed-off-by: Greg Kroah-Hartman

serial: Fix divide-by-zero fault in uart_get_divisor()

2014-11-14T17:00:02+00:00

commit 547039ec502076e60034eeb79611df3433a99b7d upstream.

uart_get_baud_rate() will return baud == 0 if the max rate is set
to the "magic" 38400 rate and the SPD_* flags are also specified.
On the first iteration, if the current baud rate is higher than the
max, the baud rate is clamped at the max (which in the degenerate
case is 38400). On the second iteration, the now-"magic" 38400 baud
rate selects the possibly higher alternate baud rate indicated by
the SPD_* flag. Since only two loop iterations are performed, the
loop is exited, a kernel WARNING is generated and a baud rate of
0 is returned.

Reproducible with:
 setserial /dev/ttyS0 spd_hi base_baud 38400

Only perform the "magic" 38400 -> SPD_* baud transform on the first
loop iteration, which prevents the degenerate case from recognizing
the clamped baud rate as the "magic" 38400 value.

Reported-by: Robert Święcki 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: omap-serial: fix division by zero

2014-10-30T16:38:22+00:00

commit dc3187564e61260f49eceb21a4e7eb5e4428e90a upstream.

If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in serial_omap_is_baud_mode16() may become 0. This
causes a division by zero when calculating the difference between
calculated and desired baud rates. To prevent this, cap the n13 and n16
values on 1.

Division by zero in kernel.
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (Ldiv0+0x8/0x10)
[] (Ldiv0) from [] (serial_omap_baud_is_mode16+0x4c/0x68)
[] (serial_omap_baud_is_mode16) from [] (serial_omap_set_termios+0x90/0x8d8)
[] (serial_omap_set_termios) from [] (uart_change_speed+0xa4/0xa8)
[] (uart_change_speed) from [] (uart_set_termios+0xa0/0x1fc)
[] (uart_set_termios) from [] (tty_set_termios+0x248/0x2c0)
[] (tty_set_termios) from [] (set_termios+0x248/0x29c)
[] (set_termios) from [] (tty_mode_ioctl+0x1c8/0x4e8)
[] (tty_mode_ioctl) from [] (tty_ioctl+0xa94/0xb18)
[] (tty_ioctl) from [] (do_vfs_ioctl+0x4a0/0x560)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x4c/0x74)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30)

Signed-off-by: Frans Klaver 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Add Quark X1000 to 8250_pci.c

2014-10-15T06:36:43+00:00

commit 1ede7dcca3c4fa15a518ab0473126f9c3e621e4c upstream.

Quark X1000 contains two designware derived 8250 serial ports.
Each port has a unique PCI configuration space consisting of
BAR0:UART BAR1:DMA respectively.

Unlike the standard 8250 the register width is 32 bits for RHR,IER etc
The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a
bitrate of up to about 2.76 megabits per second.

This patch enables standard 8250 mode

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman