[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>

drivers/serial/mux.c

@@ -477,6 +477,13 @@ static int __init mux_probe(struct parisc_device *dev)
 		port->ops	= &mux_pops;
 		port->flags	= UPF_BOOT_AUTOCONF;
 		port->line	= port_cnt;
+
+		/* The port->timeout needs to match what is present in
+		 * uart_wait_until_sent in serial_core.c.  Otherwise
+		 * the time spent in msleep_interruptable will be very
+		 * long, causing the appearance of a console hang.
+		 */
+		port->timeout   = HZ / 50;
 		spin_lock_init(&port->lock);
 		status = uart_add_one_port(&mux_driver, port);
 		BUG_ON(status);