On Thursday 24 July 2003 22:20, Alan Stern wrote: >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
Just for grins Alan, are you going to make a single big patch for 2.4.22-pre7 or so available when the dust has settled with this rework? -- Cheers, gene gheskett at wdtv dot com 99.27% setiathome rank, not too bad for a WV hillbilly ------------------------------------------------------- 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
