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

[Hans Petter Selasky]

The following reply was made to PR usb/149675; it has been noted by GNATS.

From: Hans Petter Selasky <hselasky at c2i.net>
To: freebsd-usb at freebsd.org
Cc: Paul Thornton <prt at prt.org>,
 freebsd-gnats-submit at freebsd.org,
 ed at freebsd.org
Subject: Re: usb/149675: uftdi doesn't react to break properly
Date: Sun, 15 Aug 2010 19:47:04 +0200

 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