> Either we'd have to call tty_port->rx a character at a time or > implement some temporary buffer. I don't think we want to call things > like BT receive code a byte at a time. This needs to be a layer > higher. flush_to_ldisc either needs to be duplicated to handle > tty_port->rx or generalized to call either tty_port->rx or ldisc > receive_buf. I'm not sure what to do about ldisc ref counting in the > latter case. You already have the buffer What I was trying to suggest was that instead of chars->buffer flush workqueue loop pushing data into the ldisc You can also do chars->buffer flush workqueue ->rx() [where flush_to_ldisc is just one implementation of ->rx] For byte by byte ports it really makes no difference (except you would be able to do processing without an ldisc), but for DMA devices it would give us a faster path for processing since the DMA completion event can simply fire a buffer a characters directly at the protocol handler where there are not latency concerns (ie it starts the new DMA and directly involves ->rx()) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
