BTW, something to keep in mind here is that there are actually *three*
buffers -- one on the chip/device, one in the com driver, and one in
the tty layer.

It's already the case that, if hardware flow control is enabled, the
com driver will keep data that doesn't fit in the tty buffer, until it
drains and the tty layer wakes it up again.  I wrote that code.  (I
would have made it do this in the case where there is no flow control,
but for the fact that there was no interface from the tty layer to
notify the driver when the tty buffer drains in that case.)

If the com driver's buffer overflows, or if the chip/device's buffer
overflows, you should get messages logged by the kernel (`ibuf floods'
and `silo overflows', respectively).  If you don't see these, you
should look elsewhere for whatever your problem is.

One common reason for the tty layer to overflow is that it depends on
applications actually reading the data.  This isn't a problem for
in-kernel PPP, but it's often that case that, e.g., kermit will
overflow the buffer by stalling while it's doing disk I/O.  This was
the main incentive to add the overflow logic (that and being able to
assert backpressure and actually turn off receive interrupts when
we're really screwed, avoiding livelock).