On Wed, Mar 10, 2010 at 12:46:55AM -0800, David Brownell wrote: > On Tuesday 09 March 2010, Greg KH wrote: > > On Tue, Mar 09, 2010 at 05:16:40PM +0200, Felipe Balbi wrote: > > > On Tue, Mar 09, 2010 at 06:54:30AM -0800, Greg KH wrote: > > > > Why is this needed? Why not just use the serial driver instead? That > > > > should provide you with exactly the same end result, right? > > > > > > we experienced several problems with tty layer. The biggest of them is > > > a race between flush_to_ldisc() and ->receiv_buf() which makes the line > > > discipline (I guess only n_tty) loose bytes in some circumstances. > > > > That sounds like a bug we need to fix then, right? > > That was my reaction too. (Long time since I looked at this, but I > recall problems there in the past...) > > > ISTR when writing u_serial that the TTY layer was still in flux, so > it was unclear how to do some things that should have been routine. > Various buffering policies did not seem to be stable. I recall that > the original serial gadget code had a bunch of cases where it would > lose when trying to push a lot of data ... I fixed quite a few bugs > in such logic, but don't think I got all of them ... many of the > TTY layer policies were evolving at the time. > > Locking in the TTY layer was another thing that kept getting redefined. > (I wouldn't say "clarified"; the observed behavior was changing.) The tty layer is always in flux :) Anyway, I would be interested in seeing this all fixed up first, I'm pretty sure that the high data rates can happen in this driver that would make the char driver not be needed at all (and if you really need high speeds, then you can use a proper line dicipline as you pointed out, which will be needed anyway.) thanks, greg k-h -- 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
