Date: Sun, 15 Aug 2010 18:00:12 GMT From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-usb@FreeBSD.org Subject: Re: usb/149675: uftdi doesn't react to break properly Message-ID: <201008151800.o7FI0C5G016681@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR usb/149675; it has been noted by GNATS. From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-usb@freebsd.org Cc: Paul Thornton <prt@prt.org>, freebsd-gnats-submit@freebsd.org, ed@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008151800.o7FI0C5G016681>