G'Morning,
On Wednesday 13 October 2004 6:51 am, Alan Stern wrote:
> On Tue, 12 Oct 2004, David Brownell wrote:
>
> > There are two cases where an HCD needs records
> > to be invalidated (unless it's UHCI or other hardware that doesn't
> > "know" such things:
> >
> > (a) HCD records endpoint address, which changes after SET_ADDRESS.
> > that's what this patch addressed.
>
> I'm not clear on this. My assumption was that the controllers and drivers
> kept track of things by device address and endpoint number (both found in
> urb->pipe). The change resulting from SET-ADDRESS wouldn't matter then,
> because the address would be different so it would look like a completely
> different queue.
Historically, HCDs have used two things to identify the queue: The
endpoint ID from the pipe (equating ep0in and ep0out); and the
struct usb_device used to hold the queues. (Or maybe I should
say "HCDs other than UHCI".)
> But you're implying the driver uses the usb_device
> struct (or maybe the embedded devnum field) as well, so that somehow it
> realizes that ep0 at address 0 and ep0 at the new address really are the
> same queue. Is that right?
Well, not about "implying" -- stating! OHCI has associated queues
with the devices since 2.2.early, and EHCI has done the same since
its earliest incarnations too. The device address is associated with
the QH (and for EHCI ISO support, the ITDs ... UHCI-like). SET_ADDRESS
is all about invalidating such associations and creating new ones.
> > (b) HCD records ep0maxpacket, which usbcore may have guessed
> > wrong for full speed devices.
> >
> > Only an issue for ep0, only during enumeration, only those cases.
> > Separate "scrub that state" calls are appropriate.
>
> Do you think it would be a good precaution to scrub the state for address
> 0 _before_ doing anything, just in case there's any leftover garbage?
Nah; the initial state of a device is "no endpoint queues".
- Dave
p.s. Strictly speaking I should have listed (c) SET_CONFIGURATION
invalidates all endpoints other than ep0 ... but that works fine
lately, and the relevant bug is way earlier than that.
> Alan Stern
>
>
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
