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. Summed up I guess that this part is still missing in the PL2303 module. I have tried to have a look on it, but I am not really expert there. And then I have also no idea how the chip informs the host that it buffers had been filled on (where is a protocol description?). I have only found this old driver code, no idea if it is of any use: http://www.madingley.org/james/pl2303/index.html Did anyone have a similar experience to me? Thanks, Matthias Wallnöfer -- 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
