aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/serial/8250.c
diff options
context:
space:
mode:
authorMauro Carvalho Chehab <mchehab@redhat.com>2009-02-20 18:38:52 -0500
committerLinus Torvalds <torvalds@linux-foundation.org>2009-02-20 20:57:50 -0500
commitb6adea334c6c89d5e6c94f9196bbf3a279cb53bd (patch)
treefa4360d5522309a8dd9a3fced5e0f8b53de90d85 /drivers/serial/8250.c
parent3cf311409d37d904335eb720e8a6b2c17bee6698 (diff)
8250: fix boot hang with serial console when using with Serial Over Lan port
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 <mchehab@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/serial/8250.c')
-rw-r--r--drivers/serial/8250.c15
1 files changed, 15 insertions, 0 deletions
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 0d934bfbdd9b..b4b39811b445 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2083,6 +2083,20 @@ static int serial8250_startup(struct uart_port *port)
2083 2083
2084 serial8250_set_mctrl(&up->port, up->port.mctrl); 2084 serial8250_set_mctrl(&up->port, up->port.mctrl);
2085 2085
2086 /* Serial over Lan (SoL) hack:
2087 Intel 8257x Gigabit ethernet chips have a
2088 16550 emulation, to be used for Serial Over Lan.
2089 Those chips take a longer time than a normal
2090 serial device to signalize that a transmission
2091 data was queued. Due to that, the above test generally
2092 fails. One solution would be to delay the reading of
2093 iir. However, this is not reliable, since the timeout
2094 is variable. So, let's just don't test if we receive
2095 TX irq. This way, we'll never enable UART_BUG_TXEN.
2096 */
2097 if (up->port.flags & UPF_NO_TXEN_TEST)
2098 goto dont_test_tx_en;
2099
2086 /* 2100 /*
2087 * Do a quick test to see if we receive an 2101 * Do a quick test to see if we receive an
2088 * interrupt when we enable the TX irq. 2102 * interrupt when we enable the TX irq.
@@ -2102,6 +2116,7 @@ static int serial8250_startup(struct uart_port *port)
2102 up->bugs &= ~UART_BUG_TXEN; 2116 up->bugs &= ~UART_BUG_TXEN;
2103 } 2117 }
2104 2118
2119dont_test_tx_en:
2105 spin_unlock_irqrestore(&up->port.lock, flags); 2120 spin_unlock_irqrestore(&up->port.lock, flags);
2106 2121
2107 /* 2122 /*