lkml.org 
[lkml]   [2004]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Correctly flush 8250 buffers, notify ldisc of line status changes.
From
Date
On Tue, 2004-11-09 at 13:17 +0000, Alan Cox wrote:
> What the callback does is provide a notification *before* the data
> arrives, and easily 2mS out which calls a line discipline function that
> cannot sleep and cannot viably interact with the data stream.

Actually I needed it to respond to CTS going away, and it provides a
notification *before* the data are *sent*. Which lets me know that the
first bytes of my packet were dropped by the automatic contention
detection circuitry and I need to flush the rest of the packet from the
FIFO rather than letting the hardware driver wait for CTS to come back
then then send a corrupt half-packet.

> Now when you add it to the flip buffer as another event like errors the
> line discipline knows the approximate time it occurred, has defined
> semantics for ordering and queuing and can respond by flipping its modem
> signals. You can actually *use* it to implement things like half-duplex
> and multidrop.

That solves a different problem, and isn't quite as useful to me. I want
to be able to respond to CTS going low as quickly as possible, by
flushing the rest of the characters from the outgoing queue. I was happy
enough with using a tasklet to actually call the flush method, to avoid
the deadlock you pointed out without changing the locking of all the
hardware drivers).

> Andrew - please reject the patch.

I'll submit the bit which makes the flush_buffer method work on its own.
Alan, would you care to offer a viable alternative which solves the
problem I'm interested in?

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.052 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site