From: "Stuart MacDonald" <stuartm@connecttech.com>
To: "Val Henson" <val@nmt.edu>, "Theodore Tso" <tytso@valinux.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drivers/char/serial.c bug in ST16C654 detection
Date: Mon, 14 May 2001 15:50:01 -0400 [thread overview]
Message-ID: <033101c0dcaf$10557f40$294b82ce@connecttech.com> (raw)
In-Reply-To: <20010511182723.M18959@boardwalk>
From: "Val Henson" <val@nmt.edu>
> This fixes a bug in the autoconfig_startech_uarts function in
> serial.c. The problem is that 0's are written to the baud rate
> registers in order to detect an XR16C850 or XR16C854. This makes the
> Exar ST16C654 go kablooey. Saving and restoring the baud rate
> registers after the test fixes it.
What version of serial.c? I'm assuming 5.05.
Define "go kablooey". We haven't noticed any problems, and we supplied
this bit of code.
The size_fifo() routine supplies its own baud rate divisor, and
on any rs_open() change_speed() sets the baud rate properly.
I can't figure what you might be seeing.
> I'm assuming that the XR16C85[04] detection works as is and doesn't
> need the original baud rate restored. If I'm wrong, I'll rewrite the
> patch.
You're correct that the detection works as is, except that you
broke it in your patch. See below.
> --- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
> +++ linux/drivers/char/serial.c Sat May 12 05:19:26 2001
> @@ -3507,7 +3507,7 @@
> struct serial_state *state,
> unsigned long flags)
> {
> - unsigned char scratch, scratch2, scratch3;
> + unsigned char scratch, scratch2, scratch3, scratch4;
>
> /*
> * First we check to see if it's an Oxford Semiconductor UART.
> @@ -3551,17 +3551,32 @@
> * XR16C854.
> *
> */
> +
> + /* Save the DLL and DLM */
> +
> serial_outp(info, UART_LCR, UART_LCR_DLAB);
> + scratch3 = serial_inp(info, UART_DLL);
> + scratch4 = serial_inp(info, UART_DLM);
> +
> serial_outp(info, UART_DLL, 0);
> serial_outp(info, UART_DLM, 0);
> - state->revision = serial_inp(info, UART_DLL);
> + scratch2 = serial_inp(info, UART_DLL);
This isn't necessary. The revision field is only checked
for 950s, so setting it here doesn't harm anything. If the
current (only) example of checking it is followed as normal
procedure, the port type will always be checked first, before
checking the revision, ensuring only valid revisions are
referenced.
> scratch = serial_inp(info, UART_DLM);
> serial_outp(info, UART_LCR, 0);
> +
> if (scratch == 0x10 || scratch == 0x14) {
> + if (scratch == 0x10)
> + state->revision = scratch2;
> state->type = PORT_16850;
> return;
> }
Only saving the revision for 850s is probably wrong. It should
be saved for all the 85x uarts.
> + /* Restore the DLL and DLM */
> +
> + serial_outp(info, UART_LCR, UART_LCR_DLAB);
> + serial_outp(info, UART_DLL, scratch3);
> + serial_outp(info, UART_DLM, scratch4);
> + serial_outp(info, UART_LCR, 0);
> /*
> * We distinguish between the '654 and the '650 by counting
> * how many bytes are in the FIFO. I'm using this for now,
..Stu
next prev parent reply other threads:[~2001-05-14 19:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-12 0:27 [PATCH] drivers/char/serial.c bug in ST16C654 detection Val Henson
2001-05-14 19:50 ` Stuart MacDonald [this message]
2001-05-14 22:20 ` Val Henson
2001-05-15 13:52 ` Stuart MacDonald
2001-05-16 22:12 ` Val Henson
2001-05-16 23:12 ` Theodore Tso
2001-05-17 13:49 ` Stuart MacDonald
2001-05-17 23:20 ` Val Henson
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='033101c0dcaf$10557f40$294b82ce@connecttech.com' \
--to=stuartm@connecttech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@valinux.com \
--cc=val@nmt.edu \
/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