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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox