Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> writes: >> Alan, did you have time to look at it? Are there any reasons for wanting >> to keep low_latency in ftdi_sio when it was removed from all other >> drivers processing in interrupt context (without doing work queue >> re-implementations)? > > Yes for latency handling (two layers of work queue is bad) but its the > right fix for stable. > > For upstream how does this look as a tidy up > ftdi_sio: simplify driver > > From: Alan Cox <alan@xxxxxxxxxxxxxxx> > > This does a lot of stuff that the modern buffering logic will cover itself > so remove the cruft. > > - Remove the code handling throttle half way through a packet. We have 64K > of slack and flow control is async anyway so stopping is the wrong thing > to do > - Remove various commented out bits > - Without the partial packet stuff we can remove the async queue stuff and > split it into sensible functions for URB processing and for queueing urbs > for receipt > - Remove the unused rx_bytes count. We take locks for it, we jump through > hoops for it and we never expose it. > > Signed-off-by: Alan Cox <alan@xxxxxxxxxxxxxxx> The code doesn't fall over immediately in my testing. So at first glance this appears to be as good as removing low_latency. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
