Hi, Ran into some problems with ftdi_sio breaking after upgrading to 2.6.31. Been trying to catch up with what has been done the last month in your efforts to get usb-serial into shape. Just tried out your latest patches (from Greg's patch tree) and it seems that issues still remain with serial_open, in particular with respect to the port count. The port count is incremented before calling the device specific open, but is then decremented for a short while in tty_port_block_til_read before being incremented again. Unfortunately, several drivers depend on port count for determining when to stop reading from the device. Depending on timing, port count may be zero when the first read call back is made and causing the drivers to stop reading. This is exactly what happens with the ftdi driver: Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_open Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: write_latency_timer: setting latency timer = 1 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_set_termios Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: Setting CS8 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - tty_get_baud_rate reports speed 115200 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - Baud rate set to 115200 (divisor 0x1A) on chip FT232RL Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_set_termios Turning off hardware flow control Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 0 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback: count=0, blocked_open=1 I added the last dbg to verify that port count is indeed zero after being decremented in tty_port_block_til_read (where blocked_open is also incremented). Consequently, no further read callbacks are made and read() returns 0 after timing out: Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: update_mctrl - DTR HIGH, RTS HIGH Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5402 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5402 - check /usr/include/asm/ioctls.h Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_set_termios Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: Setting CS8 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - tty_get_baud_rate reports speed 115200 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - Baud rate set to 115200 (divisor 0x1A) on chip FT232RL Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_set_termios Turning off hardware flow control Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x540b Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x540b - check /usr/include/asm/ioctls.h Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_write port 0, 32 bytes Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: data_offset set to 0 Sep 16 15:02:30 vostro kernel: ftdi_sio ttyUSB0: ftdi_write - length = 32, data = 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 32 Sep 16 15:02:30 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 0 <read() timeout here> Sep 16 15:02:31 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 0 Sep 16 15:02:31 vostro kernel: drivers/usb/serial/ftdi_sio.c: ftdi_close This is reproducible every time in my test setup, although the first run after reconnecting the device usually succeeds due to the ftdi_device latency then being set to default 16ms causing the first read callback to be made somewhat later (when port count is again non-zero). My test program works perfectly in pre-335f8514f200e63d689113d29cb7253a5c282967 builds (where tty_port_block_til_read was added) or if the ftdi_sio driver is modified to go on reading if a read callback is made during open. Is this changed semantics for port count correct, or should drivers still be able to use port count to determine when to stop reading? Regards, Johan Hovold -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
