I'm trying to understand an issue I'm having with the ftdi_sio driver. Basically, I have a device which contains an FT2232D chip that I'm trying to communicate with from an embedded controller. When I open a tty port on the device (using "screen /dev/ttyUSB1 115200") I'm able to send characters to the device but I cannot read anything from it. When I turn on debug logging in the ftdi driver I get the following: [ 44.630000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 [ 44.630000] drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 1 [ 44.630000] drivers/usb/serial/ftdi_sio.c: Status only: 361o 140o [ 44.650000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 [ 44.650000] drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 1 [ 44.650000] drivers/usb/serial/ftdi_sio.c: Status only: 361o 140o [ 44.670000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 [ 44.670000] drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 1 [ 44.670000] drivers/usb/serial/ftdi_sio.c: Status only: 361o 140o [ 44.690000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 [ 44.690000] drivers/usb/serial/ftdi_sio.c: (this is ok on close) nonzero read bulk status received: -75 [ 45.250000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5401 [ 45.250000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5401 - check /usr/include/asm/ioctls.h [ 45.270000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5401 [ 45.270000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5401 - check /usr/include/asm/ioctls.h [ 45.290000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5402 [ 45.290000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5402 - check /usr/include/asm/ioctls.h [ 45.310000] drivers/usb/serial/ftdi_sio.c: ftdi_set_termios [ 45.310000] drivers/usb/serial/ftdi_sio.c: Setting CS8 [ 45.320000] drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - tty_get_baud_rate reports speed 115200 [ 45.330000] drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - Baud rate set to 115200 (divisor 0x1A) on chip FT2232C [ 45.340000] drivers/usb/serial/ftdi_sio.c: ftdi_set_termios Turning off hardware flow control [ 45.350000] drivers/usb/serial/ftdi_sio.c: ftdi_tiocmset TIOCMSET [ 45.360000] drivers/usb/serial/ftdi_sio.c: update_mctrl - DTR HIGH, RTS HIGH [ 45.370000] drivers/usb/serial/ftdi_sio.c: ftdi_write port 1, 2 bytes [ 45.380000] drivers/usb/serial/ftdi_sio.c: data_offset set to 0 [ 45.390000] ftdi_sio ttyUSB1: ftdi_write - length = 2, data = 0d 0a [ 45.400000] drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 2 [ 45.400000] drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 1 [ 45.520000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x541b [ 45.520000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x541b - check /usr/include/asm/ioctls.h [ 45.540000] drivers/usb/serial/ftdi_sio.c: ftdi_write port 1, 5 bytes [ 45.540000] drivers/usb/serial/ftdi_sio.c: data_offset set to 0 [ 45.550000] ftdi_sio ttyUSB1: ftdi_write - length = 5, data = 6e 70 73 0d 0a [ 45.560000] drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 5 [ 45.560000] drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 1 [ 45.580000] drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 1 [ 45.580000] drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 1 [ 45.590000] drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 1 [ 45.600000] drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 1 When the driver starts there is an endless stream of read requests until the URB failure at 44.690000 at which point all reading stops. Looking at the ftdi code in ftdi_read_bulk_callback, it appears that read requests are endlessly chained together until/unless a non-zero URB status is received at which point the read chain comes to a screeching halt. I believe my fundamental problem is the HCD that generates the -75 (overflow) error (which is probably related to development of the HCD driver for the OXU210 on our controller), but my question is this... It seems that reading will always come to a halt if an URB error occurs. While this is probably a rare event, is this a good idea? Why not restart the read URB chain after discarding the errant URB? When I actually tried to restart the read chain in the event of URB failure, I noticed was that while the reads continued, the baud rate change ioctl never happened. Not exactly sure why that is, but it seems restarting the read chain involves more that simply re-submitting the read URB to usb_submit_urb. Has anyone had a problem similar to this or understands this driver well enough to explain the proper way to restart reading? Thanks, Mike -- 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
