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
--- Begin Message ---
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/
--- End Message ---
