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
Subject: Re: usb/149675: uftdi doesn't react to break properly
Date: Sun, 15 Aug 2010 17:11:56 +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,
 
 Compile a kernel with "options USB_DEBUG". Enable FTDI debugging:
 
 sysctl hw.usb.uftdi.debug=15
 
 Do you seen any debug prints when sending BREAK?
 
 --HPS