public inbox for linux-serial@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Cole <elenstev@mesatop.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Stephen Hemminger <shemminger@osdl.org>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: Someting's busted with serial in 2.6.11 latest
Date: Thu, 10 Mar 2005 16:45:19 -0700	[thread overview]
Message-ID: <200503101645.23566.elenstev@mesatop.com> (raw)
In-Reply-To: <20050310225939.G1044@flint.arm.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

On Thursday 10 March 2005 03:59 pm, Russell King wrote:
> On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
> > I'll test current bk tonight, but I don't see any recent fix to
> > drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.
> 
> Ok, so Stephen's bug is already fixed.  After testing the latest bk, if
> you find your bug isn't resolved, please try to isolate the change by
> applying this patch.  If this doesn't resolve it, then your change of
> behaviour hasn't been caused by changes to 8250.c, but must be down to
> some other part of the kernel.
> 
> ===== linux-2.6-rmk/drivers/serial/8250.c 1.97 vs 1.95 =====
> --- 1.97/drivers/serial/8250.c	2005-03-08 10:04:55 +00:00
> +++ 1.95/drivers/serial/8250.c	2005-02-28 16:05:18 +00:00
> @@ -642,7 +642,6 @@
>  static void autoconfig_16550a(struct uart_8250_port *up)
>  {
>  	unsigned char status1, status2;
> -	unsigned int iersave;
>  
>  	up->port.type = PORT_16550A;
>  	up->capabilities |= UART_CAP_FIFO;
> @@ -729,7 +728,6 @@
>  	serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
>  	status2 = serial_in(up, UART_IIR) >> 5;
>  	serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
> -	serial_outp(up, UART_LCR, 0);
>  
>  	DEBUG_AUTOCONF("iir1=%d iir2=%d ", status1, status2);
>  
> @@ -738,40 +736,6 @@
>  		up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
>  		return;
>  	}
> -
> -	/*
> -	 * Try writing and reading the UART_IER_UUE bit (b6).
> -	 * If it works, this is probably one of the Xscale platform's
> -	 * internal UARTs.
> -	 * We're going to explicitly set the UUE bit to 0 before
> -	 * trying to write and read a 1 just to make sure it's not
> -	 * already a 1 and maybe locked there before we even start start.
> -	 */
> -	iersave = serial_in(up, UART_IER);
> -	serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
> -	if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
> -		/*
> -		 * OK it's in a known zero state, try writing and reading
> -		 * without disturbing the current state of the other bits.
> -		 */
> -		serial_outp(up, UART_IER, iersave | UART_IER_UUE);
> -		if (serial_in(up, UART_IER) & UART_IER_UUE) {
> -			/*
> -			 * It's an Xscale.
> -			 * We'll leave the UART_IER_UUE bit set to 1 (enabled).
> -			 */
> -			DEBUG_AUTOCONF("Xscale ");
> -			up->port.type = PORT_XSCALE;
> -			return;
> -		}
> -	} else {
> -		/*
> -		 * If we got here we couldn't force the IER_UUE bit to 0.
> -		 * Log it and continue.
> -		 */
> -		DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
> -	}
> -	serial_outp(up, UART_IER, iersave);
>  }
>  
>  /*
> 
> 
I am currently doing a bk pull from linux.bkbits.net/linux-2.6, and can test the above 
patch if dialup via a serial modem breaks again, but I think I already know the answer.

I first noticed this _after_ the last one-line change to drivers/serial/8250.c.
Last night, after establishing that 2.6.11-bk1 was the earliest kernel to have the problem,
and reverting the Xscale patch fixed it, I tried with last night's bk-current.
It also failed as previously described, and worked with the Xscale patch reverted.

Here is a snippet from dmesg from my current kernel (with Xscale reverted) working
on dialup.via serial modem.

[   43.034336] serio: i8042 AUX port at 0x60,0x64 irq 12
[   43.034520] serio: i8042 KBD port at 0x60,0x64 irq 1
[   43.034616] Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
[   43.034924] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   43.038087] pnp: Device 00:01.00 activated.
[   43.038329] ttyS1 at I/O 0x2f8 (irq = 10) is a 16550A

For completeness, here is the patch I applied with patch -p1 -R:

Steven

[-- Attachment #2: revert-me.patch --]
[-- Type: text/x-diff, Size: 1583 bytes --]

diff -Nru a/drivers/serial/8250.c b/drivers/serial/8250.c
--- a/drivers/serial/8250.c	2005-02-28 08:05:18 -08:00
+++ b/drivers/serial/8250.c	2005-01-24 08:00:57 -08:00
@@ -642,6 +642,7 @@
 static void autoconfig_16550a(struct uart_8250_port *up)
 {
 	unsigned char status1, status2;
+	unsigned int iersave;
 
 	up->port.type = PORT_16550A;
 	up->capabilities |= UART_CAP_FIFO;
@@ -736,6 +737,40 @@
 		up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
 		return;
 	}
+
+	/*
+	 * Try writing and reading the UART_IER_UUE bit (b6).
+	 * If it works, this is probably one of the Xscale platform's
+	 * internal UARTs.
+	 * We're going to explicitly set the UUE bit to 0 before
+	 * trying to write and read a 1 just to make sure it's not
+	 * already a 1 and maybe locked there before we even start start.
+	 */
+	iersave = serial_in(up, UART_IER);
+	serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
+	if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
+		/*
+		 * OK it's in a known zero state, try writing and reading
+		 * without disturbing the current state of the other bits.
+		 */
+		serial_outp(up, UART_IER, iersave | UART_IER_UUE);
+		if (serial_in(up, UART_IER) & UART_IER_UUE) {
+			/*
+			 * It's an Xscale.
+			 * We'll leave the UART_IER_UUE bit set to 1 (enabled).
+			 */
+			DEBUG_AUTOCONF("Xscale ");
+			up->port.type = PORT_XSCALE;
+			return;
+		}
+	} else {
+		/*
+		 * If we got here we couldn't force the IER_UUE bit to 0.
+		 * Log it and continue.
+		 */
+		DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
+	}
+	serial_outp(up, UART_IER, iersave);
 }
 
 /*

  reply	other threads:[~2005-03-10 23:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09 23:50 Someting's busted with serial in 2.6.11 latest Stephen Hemminger
2005-03-10 19:53 ` Russell King
2005-03-10 22:40   ` Steven Cole
2005-03-10 22:51     ` Russell King
2005-03-10 22:54       ` Stephen Hemminger
2005-03-10 22:59     ` Russell King
2005-03-10 23:45       ` Steven Cole [this message]
2005-03-11  1:04       ` Steven Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200503101645.23566.elenstev@mesatop.com \
    --to=elenstev@mesatop.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox