> How about we require driver level locking for interface level control > requests?
How would that be enforced? > Like if you want to disable a port, you are required to do it through > the hub driver (in some other way we haven't defined yet). That we way > ensure coherency with any loaded drivers. Actually for hubs it'd be class requests, not interface level ones. (Mostly USB_RECIP_OTHER except for some features and descriptors that are USB_RECIP_DEVICE.) In that case I think it'd be simple to just provide some hub driver APIs. (In usbcore; we have a few already, mostly HCD-only except for that magic port reset code used by usb-storage.) > If the driver is not loaded then you can do whatever you want. That'd require a "who's making this request" hook that we don't have, and some kind of checking (based on wIndex I guess, though I think using that to specify interfaces isn't required...) against who's making it and what interface it's going to (USB_RECIP_INTERFACE). >>>We need some sort of queuing, but I'm not quite convinced it needs to be >>>in the HCD itself like bulk is. Wouldn't queuing in the core be >>>sufficient? >> >>It'd be turned off for everything except usb/host/*uhci* though, which >>to me makes it sound more like a UHCI-specific feature. It's not that >>it couldn't work (now that we have a layer to hang such support on!), >>but that it's not necessary (or IMHO appropriate) at that level > > I can only see 2 reasons for putting it into the HCD: OHCI and EHCI > handle it implicitily and for speed. I don't see how UHCI handles it any less implicitly ... it's all just an HC pulling data out of queues set up by an HCD. All the HCDs have logic to scan those TD queues and "do the right thing"; once you get done with the TD for the status ACK, the next request is just the next one in the HC's queue. Third reason: keeping generic code layers truly generic! :) > There is a strong desire to keep bulk fast, but I can't come up with a > reason for control to be faster. On the other hand I can't come up with a reason to want them to be particularly slow, either ... :) There might be another reason to want framework level support for queuing though: enforcing sequencing between EP0-IN and EPO-OUT control endpoints. That'd only be a real issue for drivers that issue multiple async control requests, which bypass the synchronous wrappers. Such drivers could just as well submit the "next" control request in the completion function for the first one though. - Dave _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
