Say you fill up the tty buffer using the last of the sixteen buffers andThat's a good point. I did check that this was happening during testing, but looking into n_tty.c some more it seems that I probably just got lucky with n_tty_receive_buf running to completion (and so throttling) before n_tty_read got to run (and so un-throttling).
return in the else clause above, how will the tasklet ever get
re-scheduled?
[By the way, did you see Filippe Balbi's patch posted today claiming toI'd not seen that. Thanks for pointing that out.
fix a bug in n_tty which could cause data loss at high speeds?]
I was just about to submit a patch series killing the rx tasklet andMakes sense. The cdc-acm driver is certainly far more readable with your changes.
heavily simplifying the cdc-acm driver when you posted last night. I
think that if this mechanism is needed it is more straight-forwardly
implemented on top of those as they removes a lot of complexity and
makes it easier to spot corner cases such as the one pointed out above.
I would also prefer a more generic solution to the problem so that weI was thinking about this too. Would it be good enough to add the ability for forcing tty throttling and to call that instead of issuing another URB read when the space remaining in the buffer would then be less than the pending URB reads? Or would having a notification at a particular level be more useful for other drivers?
don't need to re-introduce driver buffering again. Since we already have
the throttelling mechanism in place, if we could only be notified/find
out that the tty buffers are say half-full, we could throttle (from
within the driver) but still push the remaining buffer still on the wire
as they arrive. It would of course require a guarantee that such a
throttle-is-about-to-happen notification is actually followed by (a
throttle and) unthrottle. Thoughts on that?