linux.git/drivers/tty/serial/8250, branch v3.15

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: 8250: Fix thread unsafe __dma_tx_complete function

2014-04-24T22:18:02+00:00

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

8250_core: Fix unwanted TX chars write

2014-04-24T22:18:02+00:00

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

serial: 8250: Clean up the locking for -rt

2014-03-09T06:24:53+00:00

In -RT the spin_lock_irqsave() does not spin but sleep if the lock is
taken. Before that, local_irq_save() is invoked which disables
interrupts even on -RT. Therefore local_irq_save() + spin_lock() does not
work.
In the ->sysrq and oops_in_progress case it is save to trylock the lock
i.e. this is what we do now anyway except for ->sysrq where we assume
that the lock is already taken.

The spin_lock_irqsave() grabs the lock and disables the interrupts on
vanilla (the same behavior) and on -RT it won't disable interrupts.

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
[bigeasy: add a patch description]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: change BayTrail default uartclk

2014-03-09T06:24:53+00:00

The Intel BayTrail HSUART power-on default reference clock is 44.2368 MHz,
but 73.728 MHz provides 0% error for additional "conventional" baud rates
above 460800 (e.g. 576000, 921600, and 1152000).

Signed-off-by: Aaron Sierra 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: more BayTrail error-free bauds

2014-03-09T06:24:53+00:00

Support the following additional baud rates with 0% error:
	500000, 1500000, 2500000, 3500000

Signed-off-by: Aaron Sierra 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

drivers/tty/serial: deal with 8250_core.c uninitialized warning for good

2014-03-01T00:25:47+00:00

Every couple of months, someone sends a patch to fix:

drivers/tty/serial/8250/8250_core.c: In function 'serial_unlink_irq_chain':
drivers/tty/serial/8250/8250_core.c:1712:2: warning: 'i' may be used uninitialized in this function [-Wuninitialized]

and they in turn get a NACK for their efforts, and are told that
their compiler is broken.  This has been going on since at least
the year 2008:  https://lkml.org/lkml/2008/11/24/433

Lets add a comment, so that subsequent patches don't get as far as
the maintainers or the mailing lists.

Acked-by: Alan Cox 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Support XR17V35x fraction divisor

2014-02-13T18:02:19+00:00

The Exar XR17V35x family of UARTs have an additional fractional divisor
register (DLD) which was not being used. Calculate and set this
register for these devices to reduce their baud rate error.

Signed-off-by: Joe Schultz 
Signed-off-by: Aaron Sierra 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: unbreak last serial ports on NetMos 9865 cards

2014-02-13T17:57:33+00:00

Aparently 9865 uses standard BAR encoding scheme (unlike 99xx cards).
Current pci_netmos_9900_setup() uses wrong BAR indices for the 9865 PCI
device, function 2. Using standard BAR indices makes all 6 ports work
for me. Thus disable the NetMos 9900 quirk for NetMos 9865 pci device.

For the reference, here is the relevant part of lspci for my device:

02:07.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI
9865 Multi-I/O Controller (prog-if 02 [16550])
	Subsystem: Device a000:1000
	Flags: bus master, medium devsel, latency 32, IRQ 17
	I/O ports at ac00 [size=8]
	Memory at fcfff000 (32-bit, non-prefetchable) [size=4K]
	Memory at fcffe000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [48] Power Management version 2
	Kernel driver in use: serial

02:07.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI
9865 Multi-I/O Controller (prog-if 02 [16550])
	Subsystem: Device a000:1000
	Flags: bus master, medium devsel, latency 32, IRQ 18
	I/O ports at a800 [size=8]
	Memory at fcffd000 (32-bit, non-prefetchable) [size=4K]
	Memory at fcffc000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [48] Power Management version 2
	Kernel driver in use: serial

02:07.2 Communication controller: MosChip Semiconductor Technology Ltd.
PCI 9865 Multi-I/O Controller
	Subsystem: Device a000:3004
	Flags: bus master, medium devsel, latency 32, IRQ 19
	I/O ports at a400 [size=8]
	I/O ports at a000 [size=8]
	I/O ports at 9c00 [size=8]
	I/O ports at 9800 [size=8]
	Memory at fcffb000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [48] Power Management version 2
	Kernel driver in use: serial

Signed-off-by: Dmitry Eremin-Solenikov 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: fix compilation warning when !CONFIG_PM_SLEEP

2014-02-13T17:57:33+00:00

CONFIG_PM will be set if either or both CONFIG_PM_SLEEP and
CONFIG_PM_RUNTIME is set. Compiling the driver with !CONFIG_PM_SLEEP causes
following compilation warnings:

drivers/tty/serial/8250/8250_dw.c:404:12: warning: ‘dw8250_suspend’ defined but not used [-Wunused-function]
drivers/tty/serial/8250/8250_dw.c:413:12: warning: ‘dw8250_resume’ defined but not used [-Wunused-function]

Fix this by using CONFIG_PM_SLEEP instead.

Signed-off-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman