usb/149675: uftdi doesn't react to break properly

[Hans Petter Selasky]

On Sunday 15 August 2010 16:31:20 Paul Thornton wrote:
> >Number:         149675
> >Category:       usb
> >Synopsis:       uftdi doesn't react to break properly
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       medium
> >Responsible:    freebsd-usb
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Sun Aug 15 14:40:00 UTC 2010
> >Closed-Date:
> >Last-Modified:
> >Originator:     Paul Thornton
> >Release:        8.1-RELEASE
> >Organization:
> 
> >Environment:
> FreeBSD base01.local 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Sun Aug 15
> 09:38:55 UTC 2010     root at base01.local:/usr/src/sys/i386/compile/TEST2 
> i386
> 
> The same issue is seen with GENERIC kernel
> 
> >Description:
> When setting the BRKINT and ~IGNBRK options on a handle where the
> underlying hardware has an FTDI chipset driven by uftdi and ucom, the
> break condition is not correctly acted upon.  The underlying hardware is
> an FTDI FT232BL chip.
> 
> The expected behaviour is that the buffer be flushed on reception of a
> break when BRKINT is used, however the driver appears to behave as if
> BRKINT is clear, as an additional 0x00 byte is seen and the buffer isn't
> flushed.
> 
> FreeBSD 7.2 and 8.0 also exhibit the same behaviour.
> 
> Using the same test program, and same USB hardware, Linux behaves as per
> documentation and flushes the buffer on reception of the break when BRKINT
> is set.
> 
> >How-To-Repeat:
> Connect two machines using ftdi-driven hardware.
> 
> Send a break followed by some data A.  Send another break, followed by some
> data B.
> 
> The correct response should be that on the receiver the buffer is flushed
> by both breaks, and a read will only return the data B.
> 
> What is likely to be read, however, is: 0x00 [A A A A A] 0x00 [B B B B B]
> 
> The code I was using which brought this issue to light can be downloaded
> from: http://www.prt.org/dmxrx2.c
> 

Hi,

I believe the following patch will fix your problem. Please apply and rebuild 
kernel / ucom module.

--HPS

--- sys/dev/usb/serial/usb_serial.c
+++ sys/dev/usb/serial/usb_serial.c
@@ -942,6 +942,7 @@
        uint8_t new_msr;
        uint8_t new_lsr;
        uint8_t onoff;
+       uint8_t lsr_delta;
 
        tp = sc->sc_tty;
 
@@ -965,6 +966,7 @@
                return;
        }
        onoff = ((sc->sc_msr ^ new_msr) & SER_DCD);
+       lsr_delta = (sc->sc_lsr ^ new_lsr);
 
        sc->sc_msr = new_msr;
        sc->sc_lsr = new_lsr;
@@ -977,6 +979,27 @@
 
                ttydisc_modem(tp, onoff);
        }
+
+       if ((lsr_delta & ULSR_BI) && (sc->sc_lsr & ULSR_BI)) {
+
+               DPRINTF("BREAK detected\n");
+
+               ttydisc_rint(tp, 0, TRE_BREAK);
+       }
+
+       if ((lsr_delta & ULSR_FE) && (sc->sc_lsr & ULSR_FE)) {
+
+               DPRINTF("Frame error detected\n");
+
+               ttydisc_rint(tp, 0, TRE_FRAMING);
+       }
+
+       if ((lsr_delta & ULSR_PE) && (sc->sc_lsr & ULSR_PE)) {
+
+               DPRINTF("Parity error detected\n");
+
+               ttydisc_rint(tp, 0, TRE_PARITY);
+       }
 }
 
 void

See USB P4 change ID 182430 for more details.

http://p4web.freebsd.org/@@182430?ac=10