USB_EHCI_TT_NEWSCHED 最後好像還是沒有接受

是在 ehci 處理 1.1 連線的時候，出問題，所設計的 新 ehci scheduler.

但是最後好像還是沒被納入成 default:

http://permalink.gmane.org/gmane.linux.usb.general/96451
最後：

It's not a matter of sloppy coding but of design.  The main issues are:

 We don't handle siTD back link pointers.  Therefore we can't
 allow full-speed isochronous IN transfers to be scheduled in
 B-uframe 4 or later.

 We don't handle FSTN nodes in the schedule.  Therefore we can't
 allow full- or low-speed interrupt transfers to be scheduled
 in B-uframe 4 or later.  (In principle, that is -- in practice
 we do allow uframes 4 and 5, at the cost of having too few
 CSPLIT packets.)

 We don't compute the full-speed budget according to the USB 
 spec.  The spec says that budgets are to be computed in terms
 of best-case full-speed bytes, not worst-case microseconds.

 If an URB's bandwidth can't be accomodated in the current
 schedule, we don't try to rebalance the schedule to make the
 bandwidth fit.

 We don't obey various restrictions on allowable schedules.
 For example, the EHCI spec says that any full-speed isochronous
 transfer of length >= 588 bytes must be the first one in its
 frame, but we don't enforce this.

 We reserve an endpoint's bandwidth when the first URB is 
 submitted rather than when the alternate setting is installed.

There's a bunch of smaller issues under each of those categories, but 
those are the biggies.

Alan Stern