Hi, > > That at least matches the labeling on the chip, so I guess that might be > > correct? > > Then it's an HX (even if the driver algorithm for detecting the type may > be wrong). Well, I do own at least one USB RS232 adapter that I very much suspect being a fake pl2303--though the chip is buried in plastic, so no clue whether it is fake-labeled. It has the pl2303 device ID and basically works, but it swallows two byte values in one direction, don't remember which (but not ^S/^Q). So ... well, who really knows? ;-) > The compiler would inline the function, and this isn't a hot path > anyway. I was talking only about cognitive overhead ... > > I am not sure I understand. Are you saying your device exhibits IXANY > > behaviour if you enable IXON with the patch applied? Mine definitely does > > not, I just re-checked, it receives other data just fine, but only resumes > > transmission when ^Q is received. > > Mine exhibits the same behaviour *as yours*. Ah, OK, that's reassuring! :-) > The usbserial code has behaved this way for decades without anyone > really complaining, and fixing this up properly would require quite a > bit of work. Well, I guess I would have complained if I had known ;-) Before I investigated how to implement this patch I just saw that s/w flow control "didn't work", but my assumption was that that was due to buffering latencies, not because the kernel just ignored the request. But then, chances are a software implementation indeed wouldn't work very well anyway for exactly that reason?! > The line discipline implementation kicks in whenever IXON is set, and > can be used as a fallback for devices where automatic hardware and > software flow control cannot be enabled concurrently in hardware for > example. Well, yeah, my guess would be that to actually make it work (well), one would need more than that? Like, implement rate control in software to keep the hardware buffers empty in order to achieve short reaction times? Which one would probably want to disable though when it's not needed in order to take advantage of the buffers? > While non-hardware assisted usb serial XON/XOFF is currently broken in > that transmission would not be halted, the line discipline would still > swallow any escape characters. Actually, that is required even for the pl2303, as it does not swallow the control characters itself. > Then please put that in the commit message (i.e. that you do not know > how to change the control characters or enable IXANY so in that case we > fall back to the broken generic implementation). I'll send v2 of the patch in a moment--I hope that I didn't miss anything ... Regards, Florian -- 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
