On Fri, 21 Jan 2005, David Brownell wrote:

> > In particular, the routine isn't careful about not copying more than
> > wLength bytes for small transfers.  
> 
> It's careful about not writing more than urb->transfer_buffer_length
> though, and insists wLength not exceed that... how then could that
> routine copy more than wLength?

One example will demonstrate the point.  Look at what happens when typeReq 
== (DeviceRequest | USB_REQ_GET_STATUS) (that's the first case in the 
big switch statement) and wLength == 0 or 1.

> > And when handling class requests 
> > there's no way for the HCD's hub_control() routine to set the proper value
> > in urb->actual_length.  (The hub_control routines aren't careful not to
> > copy more than wLength bytes either.)
> 
> Hmm, I remember thinking they wouldn't need to do that because they'd
> always be copying into a temporary buffer, but I see that's not how
> they work.  In this case, it's much better to keep all error checking
> out of the HCDs.

Agreed.

> If the temporary buffer in rh_call_control() were big enough to hold a
> usb_hub_descriptor there'd be no problem, since that's bigger than either
> hub or port status (both are LE32), and those are the only values returned
> by HCDs.  Just set "bufp" to that before calling the HCD.

Okay, I'll do that.  How do you suggest getting the actual_length value 
back from the HCD?  Interpret non-negative status return as actual_length?
Add an additional pointer-to-int argument to hub_control?  Either way, the 
HCDs will have to be changed.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to