Hello Alan
Thanks for the answer.
I'm seeing the issue on:
* Raspberry Pi with Debian6 (kernel 3.1.9+)
* Raspberry Pi with Raspbian (also kernel 3.1.9+)
* BeagleBoard xM rev. C with Ubuntu (kernel 3.1.4)
I did a much simpler test without test application, just plugging and
looking. The results are the same on all three systems:
0. Reboot and log in
1. lsmod -> no usbserial, no ftdi_sio
2. plug in the USB device (first time)
3. lsmod -> usbserial loaded, ftdi_sio loaded
4. plug out the USB device
5. lsmod -> usbserial loaded, ftdi_sio loaded
6. plug in the USB device
7. lsmod -> usbserial loaded, ftdi_sio loaded
The existence of /dev/ttyUSB0 depends on the system:
* RPi with Raspbian: /dev/ttyUSB0 never goes away after step 4.
* RPi with Debian6, BBXM: /dev/ttyUSB0 goes away after step 4 and
comes back after step 6.
The fact is that ftdi_sio and usbserial are never unloaded. That's
probably the cause of the baudrate problem.
Are there any commands I can run to provide you with more information?
Best regards,
Peter
Quoting Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>:
On Sat, 08 Sep 2012 12:14:39 +0200
peter.sheeren@xxxxxxxxx wrote:
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.
We don't do that because if you gratuitously send speed changes that have
no effect the hardware seems to reset its configuration and you lose
characters, something a lot of software doesn't expect.
If you think that if check is the problem can you replace it with an
unconditional call to change_speed(tty, port) and the re-test. That will
confirm if it is the cause.
If it is then we can think about fixing it somehow.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
