> > Clearly anyone who's interested in the value will want to know the full > > microframe number. But on the other hand, the value returned from > > ehci_get_frame() actually _is_ a frame number, so there's no way for > > drivers to learn the current microframe. Thus we have several related > > problems: How to tell whether you're dealing with frames or microframes > > and when to use each. Any suggestions on how to solve them? > > Simplest notion: define new primitives that always work in terms > of microframes, convert to using them exclusively. Full speed ISO > would ignore the LSBs. Phase out the old primitives; it's not as > if anyone can rely on them much right now ... > > Alternatively, do that but make the old primitives work right and > don't phase them out. At least, not for a year or two; this would > help if anyone actually uses those primitives right now. > > Long term -- as yo
GRR, flakey keyboard. "Long term -- as yo"u probably guessed, I'd rather just see a single programming interface for such stuff. Easier to test, document, and maintain. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
