On Mon, Aug 16, 2010 at 02:37:15PM -0400, Dave Mielke wrote: > [quoted lines by Alan Stern on 2010/08/16 at 12:01 -0400] > > >There are numerous differences in detail between the two logs. I can't > >interpret them but maybe Daniel can. However it does seem premature to > >guess that the problem is related to the USB data toggle values. > > You're right, of course. I can now give you some more information which, I > believe, tells us what the problem actually is. > > Based on Daniel's description of the various patches, I did a test within our > code. The user's device does use hardware flow control, and our code does > enable it with termios. It enables it late, though, i.e. after the device > probe. I moved the enabling of hardware flow control to beforee the device > probe and the device starts working right away. Ok, thanks. This is what I expected. I just don't understand what your 'probe' thing does. Can you outline a minimal version of your userspace code and show what it does, in which order? > It's important to note, however, that this has never been a problem with users > who connect the very same device directly to a serial port. I think, therefore, > that the problem with the ftdi_sio driver is as follows: Whether that works with your standard serial port depends on how the electrical signals are wired up on the device. If the CTS line is asserted and the end device does not care about RTS, it might work with or without hardware flow control. > I believe the DTR/RTS lines are both raised all the time on a regular serial > port when hardware flow control isn't enabled. My guess is that the ftdi_sio > driver probably sets them low when hardware flow control is disabled (or maybe > just leaves them alone). I think the fix, therefore, may be that the ftdi_sio > driver needs to force DTR/RTS both high when hardware flow control is disabled. I'm not convinced about this approach. The thing is that if your hardware does not need hardware flow control, these lines shouldn't matter at all. IOW, they should be left unconnected as the chip itself won't care either. However, if you tell the chip that you _do_ need hardware flow, it will not send out any data on TxD as long as CTS is not asserted. Daniel -- 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
