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);
}
/*
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.