Re: non-standard baud rates with Prolific 2303 USB-serial

[Johan Hovold <johan@kernel.org>]

Hi Michael,

On Thu, Feb 25, 2021 at 09:42:20AM +0100, Johan Hovold wrote:
> On Wed, Feb 24, 2021 at 01:13:39PM -0500, Michael G. Katzmann wrote:
> > On 2/24/21 12:04 PM, Johan Hovold wrote:
> > > Perhaps you can even figure out how to poll for an empty TX FIFO from
> > > it, unless Charles is able to provide some details on that separate
> > > matter?
> > 
> > I presume from the code below, that when the device is closed, all
> > data waiting to send is clobbered (if so, so the problem is the driver
> > and not the device)
> > 
> > I would have thought that the driver should drain the buffers. I can
> > see that this might be a problem if there is flow control (it may
> > never drain) but the current method seems pretty brutal.
> 
> We do; the code below isn't called until after we've waited for the
> buffers to drain (driver buffers + device FIFO).
> 
> I'll provide a patch so that you can extend the timeout for draining the
> driver buffers (defaults to 30 s), but the main problem is that we don't
> know how to query the PL2303 FIFO fill level.

I've added generic support to USB serial for setting the closing_wait
parameter through TIOCSSERIAL (e.g. setserial) so that you can change
the default 30 second timeout also with pl2303:

	https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/commit/?h=usb-next&id=01fd45f676f1b3785b7cdd5d815f9c31ddcd9dd1

With the 4k driver buffer and two bulk-out URBs with 256 bytes of data
each you need to set the timeout to something like 420 seconds at 110
bps to allow those buffers to drain (when not using flow control).

On top of that there's the 256 byte device FIFO, which we not yet know
how to query. At 110 bps that one takes about 23 seconds to drain, but
as I mentioned elsewhere we cap the time-based delay at 2 seconds
currently.

Charles, is there a way to check if the device transmit FIFO has
emptied?

Johan