linux-toradex.git/drivers/serial, branch v2.6.27.20

jsm: additional device support

2009-03-17T00:52:53+00:00

commit ffa7525c13eb3db0fd19a3e1cffe2ce6f561f5f3 upstream.

I have a Digi Neo 8 PCI card (114f:00b1) Serial controller: Digi
International Digi Neo 8 (rev 05)

that works with the jsm driver after using the following patch.

Signed-off-by: Adam Lackorzynski 
Cc: Scott H Kilau 
Cc: Wendy Xiong 
Acked-by: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

8250: fix boot hang with serial console when using with Serial Over Lan port

2009-03-17T00:52:48+00:00

commit b6adea334c6c89d5e6c94f9196bbf3a279cb53bd upstream.

Intel 8257x Ethernet boards have a feature called Serial Over Lan.

This feature works by emulating a serial port, and it is detected by
kernel as a normal 8250 port.  However, this emulation is not perfect, as
also noticed on changeset 7500b1f602aad75901774a67a687ee985d85893f.

Before this patch, the kernel were trying to check if the serial TX is
capable of work using IRQ's.

This were done with a code similar this:

        serial_outp(up, UART_IER, UART_IER_THRI);
        lsr = serial_in(up, UART_LSR);
        iir = serial_in(up, UART_IIR);
        serial_outp(up, UART_IER, 0);

        if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT)
		up->bugs |= UART_BUG_TXEN;

This works fine for other 8250 ports, but, on 8250-emulated SoL port, the
chip is a little lazy to down UART_IIR_NO_INT at UART_IIR register.

Due to that, UART_BUG_TXEN is sometimes enabled.  However, as TX IRQ keeps
working, and the TX polling is now enabled, the driver miss-interprets the
IRQ received later, hanging up the machine until a key is pressed at the
serial console.

This is the 6 version of this patch.  Previous versions were trying to
introduce a large enough delay between serial_outp and serial_in(up,
UART_IIR), but not taking forever.  However, the needed delay couldn't be
safely determined.

At the experimental tests, a delay of 1us solves most of the cases, but
still hangs sometimes.  Increasing the delay to 5us was better, but still
doesn't solve.  A very high delay of 50 ms seemed to work every time.

However, poking around with delays and pray for it to be enough doesn't
seem to be a good approach, even for a quirk.

So, instead of playing with random large arbitrary delays, let's just
disable UART_BUG_TXEN for all SoL ports.

[akpm@linux-foundation.org: fix warnings]
Signed-off-by: Mauro Carvalho Chehab 
Cc: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

serial: set correct baud_base for Oxford Semiconductor Ltd EXSYS EX-41092 Dual 16950 Serial adapter

2009-02-12T17:31:11+00:00

commit 39aced68d664291db3324d0fcf0985ab5626aac2 upstream.

The PCI-card identified as "Oxford Semiconductor Ltd EXSYS EX-41092 Dual
16950 Serial adapter" is only usable with other devices (i.e. not the same
card) after doing a "setserial /dev/ttyS baud_base 115200".  This
baud_base should be default for this card.

Signed-off-by: Niels de Vos 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Add support for '8-port RS-232 MIC-3620 from advantech'

2009-02-12T17:31:09+00:00

commit 78d70d48132ce4c678a95b771ffa1af4fb5a03ec upstream.

This Patch add the device information for the
MIC-3620 8-port RS-232 cPCI card from Advantech Co. Ltd.

Signed-off-by: Michael Bramer 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

8250_pci: add support for netmos 9835 IBM devices

2009-02-12T17:31:05+00:00

commit 25cf9bc1fcb085daaeb82b09bab0fb3c40570887 upstream.

Most of netmos 9835 hardware is handled by parport-serial.  IBM introduces
a device which doesn't have any parallel ports and have screwed subdevice
PCI id (not corresponding to port numbers).

Handle this device (9710:9835 1014:0299) properly.

Signed-off-by: Jiri Slaby 
Signed-off-by: Andrew Morton 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Add enable_ms to jsm driver

2009-02-06T22:00:35+00:00

commit 0461ec5bc7745b89a8ab67ba0ea497abd58a6301 upstream.

This fixes a crash observed when non-existant enable_ms function is
called for jsm driver.

Signed-off-by: Scott Kilau 
Signed-off-by: Paul Larson 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

serial_8250: support for Sealevel Systems Model 7803 COMM+8

2009-02-02T16:28:10+00:00

commit e65f0f8271b1b0452334e5da37fd35413a000de4 upstream.

Add support for Sealevel Systems Model 7803 COMM+8

Signed-off-by: Flavio Leitner 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

atmel_serial: update the powersave handler to match serial core

2008-09-23T15:09:14+00:00

This problem seems to be unnoticed so far:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3b708fa2780cd2b5d8266a8f0c3a1cab364d4d2

has changed the serial core behavior to not to suspend the port if the
device is enabled as a wakeup source.  If the AT91 system goes to slow
clock mode, the port should be suspended always and the clocks should be
switched off.  The patch attached updates the atmel_serial driver to match
the changes in serial core.

Also, the interrupts are disabled when the clock is disabled.  If we
disable the clock with interrupts enabled, an interrupt may get stuck.  If
this is the DBGU interrupt, this blocks the OR logic at system controller
and thus all other sysc interrupts.

Signed-off-by: Anti Sullin 
Signed-off-by: Haavard Skinnemoen 
Cc: Michael Trimarchi 
Cc: Andrew Victor 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'for-rmk' of git://pasiphae.extern.pengutronix.de/git/imx/linux-2.6.git

2008-09-13T19:11:15+00:00

8250: improve workaround for UARTs that don't re-assert THRE correctly

2008-09-03T02:21:38+00:00

Recent changes to tighten the check for UARTs that don't correctly
re-assert THRE (01c194d9278efc15d4785ff205643e9c0bdcef53: "serial 8250:
tighten test for using backup timer") caused problems when such a UART was
opened for the second time - the bug could only successfully be detected
at first initialization.  For users of this version of this particular
UART IP it is fatal.

This patch stores the information about the bug in the bugs field of the
port structure when the port is first started up so subsequent opens can
check this bit even if the test for the bug fails.

David Brownell: "My own exposure to this is that the UART on DaVinci
hardware, which TI allegedly derived from its original 16550 logic, has
periodically gone from working to unusable with the mainline 8250.c ...
and back and forth a bunch.  Currently it's "unusable", a regression from
some previous versions.  With this patch from Will, it's usable."

Signed-off-by: Will Newton 
Acked-by: Alex Williamson 
Cc: Alan Cox 
Cc: David Brownell 
Cc: 		[2.6.26.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds