Commit Graph

7 Commits

Author SHA1 Message Date
Ryan Bradetich a137ce8536 [PARISC] Define port->timeout to fix a long msleep in mux.c
This commit is in response to a bug reported by Vesa on the irc channel
a couple of weeks ago.

The bug was that the console would apparently hang (not return) while
using the mux console.

The root cause of this bug is that bash (with readline support) makes a
call to the tcsetattr() glibc function with the argument TCSADRAIN.  This
causes the serial core in the kernel use the uart_wait_until_sent() to be
called. This function verifies the mux transmit queue is empty or calls the
msleep_interruptable() with a calculated timeout value that is dependant
upon the port->timeout variable.

The real problem here is that the port->timeout was not defined so it
was defaulted to 0 and the timeout calculation performs the following
calculation:

char_time = (port->timeout - HZ/50) / port->fifosize;

where char_time is an unsigned long. Since the serial Mux does not use
interrupts, the msleep_interruptable() function waits until the timeout
has been reached ... and when the port->timeout < HZ/50 this timeout will
be a long time. (I have validated that the console will eventually
return ... but it takes quite a while for this to happen).

This patch simply sets the port->timeout on the Mux to HZ/50 to avoid
this long timeout period.

Signed-off-by: Ryan Bradetich <rbrad@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17 16:38:28 -05:00
Ryan Bradetich 92495c0ebc [PARISC] Compile fixups for serial/mux.c
This patch does the following:
* Fixes compiler warnings.
* Replaces a __raw_readl call with the existing macro.

Signed-off-by: Ryan Bradetich <rbrad@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17 16:36:52 -05:00
Matthew Wilcox ae8c75c1c4 [PARISC] Fix mux.c driver
Missing spin_lock_init() made the Mux driver hang on SMP systems.

Fix up users of ->hpa to use ->hpa.start instead

Remove warning in 8250_gsc.c by eliminating serial_line_nr

Signed-off-by: Matthew Wilcox <willy@parisc-linux.org>

Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-10-21 22:58:03 -04:00
Matthew Wilcox 53f01bba49 [PARISC] Convert parisc_device to use struct resource for hpa
Convert pa_dev->hpa from an unsigned long to a struct resource.

Signed-off-by: Matthew Wilcox <willy@parisc-linux.org>

Fix up users of ->hpa to use ->hpa.start instead.

Signed-off-by: Matthew Wilcox <willy@parisc-linux.org>

Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-10-21 22:36:40 -04:00
Matthew Wilcox bdad1f836a [PARISC] Change the driver names so /sys/bus/parisc/drivers/ looks better
Make /sys/bus/parisc/drivers look better by cleaning up parisc_driver
names.

Signed-off-by: Matthew Wilcox <willy@parisc-linux.org>

Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-10-21 22:36:23 -04:00
Russell King b129a8ccd5 [SERIAL] Clean up and fix tty transmission start/stoping
The start_tx and stop_tx methods were passed a flag to indicate
whether the start/stop was from the tty start/stop callbacks, and
some drivers used this flag to decide whether to ask the UART to
immediately stop transmission (where the UART supports such a
feature.)

There are other cases when we wish this to occur - when CTS is
lowered, or if we change from soft to hard flow control and CTS
is inactive.  In these cases, this flag was false, and we would
allow the transmitter to drain before stopping.

There is really only one case where we want to let the transmitter
drain before disabling, and that's when we run out of characters
to send.

Hence, re-jig the start_tx and stop_tx methods to eliminate this
flag, and introduce new functions for the special "disable and
allow transmitter to drain" case.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-31 10:12:14 +01:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00