Tom Rini | 8 Sep 22:54 2003

[PATCH] Make the Startech UART detection 'more correct'.

Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
detection 'more correct'  The problem is that on with the Motorola
MPC82xx line (8245 for example) it has an internal DUART that it claims
to be PC16550D compatible, and it has an additional EFR (Enhanced
Feature Register) at offset 0x2, like on the Startech UARTS.  However,
it is not a Startech, and when it's detected as such, FIFOs don't work.
The fix for this is that the Startech UARTs have a 32 byte FIFO [1] and
the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO size
is correct for a Startech.

2.4:
===== drivers/char/serial.c 1.34 vs edited =====
--- 1.34/drivers/char/serial.c	Sun Jul  6 22:33:28 2003
+++ edited/drivers/char/serial.c	Fri Sep  5 15:44:11 2003
 <at>  <at>  -3740,7 +3740,7  <at>  <at> 
 	if (state->type == PORT_16550A) {
 		/* Check for Startech UART's */
 		serial_outp(info, UART_LCR, UART_LCR_DLAB);
-		if (serial_in(info, UART_EFR) == 0) {
+		if (serial_in(info, UART_EFR) == 0 && size_fifo(info) != 16) {
 			state->type = PORT_16650;
 		} else {
 			serial_outp(info, UART_LCR, 0xBF);

2.6:
===== drivers/serial/8250.c 1.34 vs edited =====
--- 1.34/drivers/serial/8250.c	Sun Jun 15 02:21:11 2003
+++ edited/drivers/serial/8250.c	Fri Sep  5 15:43:23 2003
 <at>  <at>  -467,7 +467,7  <at>  <at> 
 	 * Only ST16C650V1 UARTs pass this test.
(Continue reading)

Russell King | 9 Sep 18:18 2003
Picon

Re: [PATCH] Make the Startech UART detection 'more correct'.

On Mon, Sep 08, 2003 at 01:54:31PM -0700, Tom Rini wrote:
> Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
> detection 'more correct'  The problem is that on with the Motorola
> MPC82xx line (8245 for example) it has an internal DUART that it claims
> to be PC16550D compatible, and it has an additional EFR (Enhanced
> Feature Register) at offset 0x2, like on the Startech UARTS.  However,
> it is not a Startech, and when it's detected as such, FIFOs don't work.
> The fix for this is that the Startech UARTs have a 32 byte FIFO [1] and
> the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO size
> is correct for a Startech.

size_fifo() is claimed to be unreliable at detecting the FIFO size,
so I don't feel safe about using it here.

I'd suggest something like:

	serial_outp(port, UART_LCR, UART_LCR_DLAB);
	efr = serial_in(port, UART_EFR);
	if ((efr & 0xfc) == 0) {
		serial_out(port, UART_EFR, 0xac | (efr & 3));
		/* if top 6 bits return zero, its motorola */
		if (serial_in(port, UART_EFR) == (efr & 3)) {
			/* motorola port */
		} else {
			/* ST16C650V1 port */
		}
		/* restore old value */
		serial_outb(port, UART_EFR, efr);
	}

(Continue reading)

Stuart MacDonald | 9 Sep 21:12 2003

RE: [PATCH] Make the Startech UART detection 'more correct'.

From: linux-kernel-owner <at> vger.kernel.org 
> size_fifo() is claimed to be unreliable at detecting the FIFO size,
> so I don't feel safe about using it here.

"Claimed" being the operative word. This claim predates my involvement
with the serial driver (IIRC tytso is reporting someone's claim
second-hand), however, my company has always used this test in various
test apps, and never had it fail, and this predates my employment with
them.

So. A number of possibilities: someone thought it was unreliable, but
they were incorrect; it was unreliable, but because the software was
wrong; it was unreliable, but only on certain very old hardware that I
personally have no knowledge of its existance.

I've never seen any concrete details about what goes wrong either,
just a simple claim of unreliability.

The premise is simple enough. Put the uart into internal loopback mode
(the rx and tx pins on the chip become on-die connected to each other,
date never leaves the chip), transmit 256 characters at a known baud
rate, wait for at least the time it takes to transmit these characters
plus some to be safe, and see how many are left in the rx fifo, which
should be full.

> I'd suggest something like:
> 
> 	serial_outp(port, UART_LCR, UART_LCR_DLAB);
> 	efr = serial_in(port, UART_EFR);
> 	if ((efr & 0xfc) == 0) {
(Continue reading)

Tom Rini | 9 Sep 21:23 2003

Re: [PATCH] Make the Startech UART detection 'more correct'.

On Tue, Sep 09, 2003 at 03:12:30PM -0400, Stuart MacDonald wrote:
> From: linux-kernel-owner <at> vger.kernel.org 
[snip]
> > I'd suggest something like:
> > 
> > 	serial_outp(port, UART_LCR, UART_LCR_DLAB);
> > 	efr = serial_in(port, UART_EFR);
> > 	if ((efr & 0xfc) == 0) {
> > 		serial_out(port, UART_EFR, 0xac | (efr & 3));
> > 		/* if top 6 bits return zero, its motorola */
> > 		if (serial_in(port, UART_EFR) == (efr & 3)) {
> > 			/* motorola port */
> > 		} else {
> > 			/* ST16C650V1 port */
> > 		}
> > 		/* restore old value */
> > 		serial_outb(port, UART_EFR, efr);
> > 	}
> > 
> > If you can guarantee that the lower two bits will always be 
> > zero, you can
> > drop the frobbing to ignore/preseve the lower two bits.
> 
> Does the Motorola chip have an ID register at all? Certainly using the
> fifo size is a weak test and should only be a last resort.

No, there is not an ID on the motorola duarts.

--

-- 
Tom Rini
(Continue reading)

Tom Rini | 10 Sep 01:51 2003

Re: [PATCH] Make the Startech UART detection 'more correct'.

On Tue, Sep 09, 2003 at 05:18:59PM +0100, Russell King wrote:

> On Mon, Sep 08, 2003 at 01:54:31PM -0700, Tom Rini wrote:
> > Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
> > detection 'more correct'  The problem is that on with the Motorola
> > MPC82xx line (8245 for example) it has an internal DUART that it claims
> > to be PC16550D compatible, and it has an additional EFR (Enhanced
> > Feature Register) at offset 0x2, like on the Startech UARTS.  However,
> > it is not a Startech, and when it's detected as such, FIFOs don't work.
> > The fix for this is that the Startech UARTs have a 32 byte FIFO [1] and
> > the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO size
> > is correct for a Startech.
> 
> size_fifo() is claimed to be unreliable at detecting the FIFO size,
> so I don't feel safe about using it here.
> 
> I'd suggest something like:
> 
> 	serial_outp(port, UART_LCR, UART_LCR_DLAB);
> 	efr = serial_in(port, UART_EFR);
> 	if ((efr & 0xfc) == 0) {
> 		serial_out(port, UART_EFR, 0xac | (efr & 3));
> 		/* if top 6 bits return zero, its motorola */
> 		if (serial_in(port, UART_EFR) == (efr & 3)) {
> 			/* motorola port */
> 		} else {
> 			/* ST16C650V1 port */
> 		}
> 		/* restore old value */
> 		serial_outb(port, UART_EFR, efr);
(Continue reading)

Sergei Organov | 18 Sep 15:42 2003
Picon

[PATCH] Fix TIOCSBRK/TIOCCBRK handling by mxser.c.

The patch below fixes TIOCSBRK/TIOCCBRK handling in 'mxser.c' by means of
defining break_ctl routine for tty_driver.

--- linux-2.4.19/drivers/char/mxser.c.old	Sat Aug  3 04:39:43 2002
+++ linux-2.4.19/drivers/char/mxser.c	Thu Sep 18 17:33:21 2003
 <at>  <at>  -29,11 +29,14  <at>  <at> 
  *
  *      for             : LINUX 2.0.X, 2.2.X, 2.4.X
  *      date            : 2001/05/01
- *      version         : 1.2 
+ *      version         : 1.2
  *      
  *    Fixes for C104H/PCI by Tim Hockin <thockin <at> sun.com>
  *    Added support for: C102, CI-132, CI-134, CP-132, CP-114, CT-114 cards
  *                        by Damian Wrobel <dwrobel <at> ertel.com.pl>
+ *    09/03: Use tty_driver.break_ctl for break control. This fixes handling
+ *           of TIOCSBRK/TIOCCBRK by the driver.
+ *                        by Sergei Organov <osv <at> topconrd.ru>
  *
  */

 <at>  <at>  -65,7 +68,7  <at>  <at> 
 #include <asm/bitops.h>
 #include <asm/uaccess.h>

-#define		MXSER_VERSION			"1.2.1"
+#define		MXSER_VERSION			"1.2.2"

 #define		MXSERMAJOR	 	174
 #define		MXSERCUMAJOR		175
(Continue reading)

Kumar Gala | 25 Sep 00:40 2003

Re: [PATCH] Make the Startech UART detection 'more correct'.

I was wondering what the status of this patch was for the 2.4 side?

thanks

- kumar

On Tuesday, September 9, 2003, at 06:51 PM, Tom Rini wrote:

> On Tue, Sep 09, 2003 at 05:18:59PM +0100, Russell King wrote:
>
>> On Mon, Sep 08, 2003 at 01:54:31PM -0700, Tom Rini wrote:
>>> Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
>>> detection 'more correct'  The problem is that on with the Motorola
>>> MPC82xx line (8245 for example) it has an internal DUART that it 
>>> claims
>>> to be PC16550D compatible, and it has an additional EFR (Enhanced
>>> Feature Register) at offset 0x2, like on the Startech UARTS.  
>>> However,
>>> it is not a Startech, and when it's detected as such, FIFOs don't 
>>> work.
>>> The fix for this is that the Startech UARTs have a 32 byte FIFO [1] 
>>> and
>>> the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO 
>>> size
>>> is correct for a Startech.
>>
>> size_fifo() is claimed to be unreliable at detecting the FIFO size,
>> so I don't feel safe about using it here.
>>
>> I'd suggest something like:
(Continue reading)

Amit Kucheria | 27 Sep 01:13 2003

persistent slip connections

Hi,

I currently use 'slattach' (actually a modified version) to setup a SLIP
connection between two machines. But when I unplug the cable and replug
it back in, I have to reconfigure the connection at both end.

Could this be handled in the slattach program, so that it does not
'hangup' due to loss of DCD or DSR?

TIA.

Regards,
Amit

--

-- 
     .| Amit Kucheria                       |.
   ...| Wireless Systems Engineer           |...
 .....| Metric Systems Corp., San Diego, CA |.....
......| www.metricsystems.com               |......

Gmane