Hi Greg, a big thank for your exhaustive explanation. Of course this scenario was more about testing than real-world experience since most serial protocols I am aware of use much shorter messages. What regards to the Prolific chip: I fully agree with you that it is a consumer IC which does not cost to much and offers enough features for 99% of the various use cases. I could try to do a test against the Windows driver, but it will probably not change in behaviour, when you are saying that this is about a design limitation. Thanks again, Matthias Wallnöfer Greg KH wrote: > On Sun, Jun 24, 2018 at 05:40:37PM +0200, Matthias Dieter Wallnöfer wrote: >> Hi people, >> >> as I am working with a PL2303-based USB-to-serial converter I discovered >> that the SW-based flow control was unsupported for all kernels till the >> upcoming 4.18 release. Thanks to the patch by Florian Zumbiehl this >> deficit was finally resolved and also my tests showed that now the flow >> characters get finally sent as one would expect it. >> >> According to my tests the HW (RTS/CTD) and SW flow control is now >> working correctly in the direction *inbound* to USB. Unfortunately I am >> less convinced that it does so also the other way around. >> >> Let me explain why: as the datasheets available on the web state, the >> chip is equipped with both internal receive and send buffers. Consider >> enabling the HW or SW flow control and filling up both the PL2303's >> internal and the device's target recv buffer, for example with a string >> of 12'000 characters (in my case it was a PC connected with a nullmodem >> link). >> >> First, the target device's buffer fills up which is fine. When the >> buffer's high watermark is reached, the Prolific chip gets informed that >> it should not send anymore. This means that now fresh chars arriving >> from the USB host end up in the internal send buffer which grows and >> grows. Filled up also this one I am not aware of any mechanism which >> informs the host to stop doing so, that in the end data gets lost. > > I think that is because this device does not have any way to do so. > > When USB to serial devices first came out, a number of devices did have > this type of capability, and it was complex. The devices that did this > also were "rock solid" but unfortunatly did not sell all that well, and > over the decades we ended up with the dirt-cheap devices we have today > without the full capabilities of old-style UARTS because it was "good > enough". > > If you really worry about this type of problem, I suggest you get one of > those other types of devices (io-edgeport is one example, I think there > are others). Last time I looked at the data sheet of the pl2303 device, > I do not think it had this type of funcationality at all. > > Also note that there are different types of this device, as well as > "cheap clones" which _almost_ work the same, but not always for some of > the "odd" features, like flow control :) > > Sorry, and good luck! > > greg k-h > -- 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
