Messages in this thread | | | Subject | Re: [PATCH] Correctly flush 8250 buffers, notify ldisc of line status changes. | From | David Woodhouse <> | Date | Tue, 09 Nov 2004 14:39:31 +0000 |
| |
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/
| |