Dave, Greg -- I think this is one problem with OPOST ONLCR and the pl2303 usb usb driver (and other usb serial drivers)--
Look at the write_chan in n_tty.c. It calls opost_block() to write a block of characters up to the first '\n', then opost() to write the '\r' and '\n', using two calls to the tty driver put_char. usbserial doesn't have a put_char, so this just gets mapped to a write of 1 byte. The problem is that these two writes come one after the other and the write of the second '\n' fails because the write urb still has status -EINPROGRESS from writing the first '\r'. There is no check for errors writing this second character, (put_char returns void) so it is just lost and you don't see the '\n'. Greg, if you remember, we talked about this a couple years ago. The put_char really needs to succeed or characters will be lost. Also, put_char could be called on interrupt time, so it couldn't sleep (don't know if that is still true). I still think that usbserial should expose put_char so usb serial drivers can handle it differently than a normal write if they want. It sounds like there are other problems with pl2303, beyond this, however. Lets try to find the root cause of these problems, rather than just forcing OPOST off in the pl2303 driver. If I have time and hardware that shows the problem I will try to look into it. Serial drivers have lots of features that might not often be used, but some applications depend on those features. -- Al ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
