Fwd: Bug in USB FTDI SIO driver

[peter.sheeren@axiris.be]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

Hello

At the suggestion of Greg's friendly e-mail bot I'm sending my report  
to this e-mail address. I hope it's the right one.

Peter


[-- Attachment #2: Forwarded Message: Bug in USB FTDI SIO driver --]
[-- Type: message/rfc822, Size: 2759 bytes --]

From: peter.sheeren@axiris.be
To: jhovold@gmail.com, greg@kroah.com
Subject: Bug in USB FTDI SIO driver
Date: Sat, 08 Sep 2012 04:21:06 +0200
Message-ID: <20120908042106.60247e3thepx3q1e@webmail.axiris.be>


Hello

I didn't find an easy way to file a bug report so I extracted the  
source file ftdi_sio.c from the latest Linux kernel and browsed for  
the e-mail addresses hence this e-mail.

I've been struggling with an annoying plug-and-play issue involving an  
FT232RL-based USB device on ARM machines with Linux lately (including  
Raspberry Pi and BeagleBoard). In a nutshell the following is happening:
* I plug in the FT232RL-based USB device. /dev/ttyUSB0 is created.
* I run an application that communicate with the device via  
/dev/ttyUSB0. The application sets a baudrate - this is important. The  
application reads and writes data successfully.
* I unplug the USB device. /dev/ttyUSB0 remains in existence - this is  
important too.
* I replug the USB device. /dev/ttyUSB0 is still there.
* I rerun the application. The application again connects with  
/dev/ttyUSB0 but it fails to transfer data. So it seems.

I ran I number of tests with a small program on my ARM based systems  
and I discovered that the culprit is setting the baudrate. It turns  
out that, after replugging the USB device, setting the baudrate is not  
relayed to the USB device.

Since this looks like a caching problem, I tracked down the  
corresponding source code in ftdi_sio.c and I'm confident the  
following text is the cause of the problem:

(line 1375)

	if (((old_priv.flags & ASYNC_SPD_MASK) !=
	     (priv->flags & ASYNC_SPD_MASK)) ||
	    (((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST) &&
	     (old_priv.custom_divisor != priv->custom_divisor))) {
		change_speed(tty, port);

Function change_speed() is called only when the baudrate  
(custom_divisor) has changed but after a USB replug this assumption is  
wrong. Also note that /dev/ttyUSB0 remains in existence on the system  
under test. If it were up to me, I'd always send the baudrate setting  
over the USB bus nomatter whether the baudrate (supposedly) has  
changed or not.

I found a workaround for this bug: my software sets a different  
baudrate prior to the intended baudrate hence fooling the ftdi_sio.c  
code but ofcourse it's a workaround.

I hope this report will help you improve your driver.

Best regards,

Peter S'heeren
http://www.axiris.be/