> Then we came to the conclusion that flush_to_ldisc() doesn't play that > nicely when ldisc has an almost full buffer (btw, I was using n_tty > ldisc). You see, the only check we have for how many bytes ldisc can > actually receive is through tty->receive_room, which for some reason (we > couldn't figure that out) isn't always up-to-date. Thats not quite how I remember it. > flush_to_ldisc() believes it can always flush everything to ldisc based > on ->receive_room only, and that's where we were loosing a few bytes and > obexd getting stuck on poll() forever waiting for the lost bytes. Which is not a bug, because an ldisc isn't permitted to shrink the receive room without data arriving and is responsible for updating it before the receive path returns. > What we did (as a hack, but I want to finish the patch and send as RFC) > is make ->receive_buf() return the amount of bytes received. Then we can > get rid of ->receive_room. Which is not be a bad idea anyway, irrespective of the underlying problem - which I suspect is some kind of n_tty internal disagreement with itself. > It's not perfect, but it help us a lot. I still don't know why the > receive_room approach was taken if it would be a lot simpler (at > least IMO)to let receive_buf() return the amount of received bytes. receive_room is historical to the extent it goes back to very early kernels and I've no idea why it was done that way. I have no problem with making it go away. Alan -- 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
