On Thu, 24 Jul 2003, David Brownell wrote: > Alan Stern wrote: > > > > You can't set periodic_iso_limit to 1024 on UHCI, because the driver > > reserves a grace period of 10 frames. The largest legal value is > > therefore UHCI_NUMFRAMES - 11.
Shortly after sending that off, I realized it was nonsense. Of course 1024 is a perfectly good value for an iso. interval. All that will happen is the HC driver will return an error if the URB contains more than one descriptor. But the generic code can't be expected to know that. > > Also, UHCI doesn't require iso. periods to > > be powers of 2. > > Last I checked, it expected period == 1 (which is a power of 2) ... but > that could have changed since then! :) Evidently it has... > But the "power-of-two" restriction comes from the USB spec, which says > that all ISO periods are encoded as log2. True enough. I had forgotten that or confused iso. intervals with interrupt intervals, where one is only guaranteed that the actual interval is <= the descriptor's value. > The generic checks can't, of necessity, cover every contingency. There's > actually a CAN_SCHEDULE_FRAMES value that I thought about using to init > the periodic_iso_limit for UHCI ... but that wouldn't work since that > value is "UHCI_NUMFRAMES - 24" (not 11?), which would break the log2 > logic a bit later. Forget it, just use UHCI_NUMFRAMES. The actual check, which will have to be carried out in the driver, is that no descriptor ends up getting scheduled for any frame later than (current_frame + 1024). That's not a restriction on the interval, though -- at least, not directly. > > There's another check that could be added to usb_submit_urb() if you're > > feeling particularly paranoid. In the loop where the iso. descriptors' > > status and actual_length fields are initialized, you could make sure that > > offset + len <= transfer_buffer_length. > > All I had time for was the quick patch to expose this information from > the HCDs, and to use it to improve the current approximations. > > You're right, that'd be a good check since otherwise a bad ISO request > could corrupt memory. I forgot to add that, because of the potential for unsigned wrap-around, you could check also that offset <= transfer_buffer_length. But that might be a little _too_ paranoid. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
