On Sat, May 25, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > >>>usb_control_msg() is probably what he wants. It waits. > >> > >>Yes. But still we should probably have control queueing for > >>the uhci's (possibly at the HCD level?) > > Queuing in the HCD seems most natural to me, in part because > all HCDs do it already for bulk and iso transfers ... and since > control and bulk are so similar to the hardware.
Well, there are some differences like status retriggering, etc which aren't trivial. Queuing at the HCD level is definately possible, but appears to be significantly more difficult than queuing in the core. I haven't given it enough thought yet to see which is the easier. > >>Think about multi-interface devices, where all interfaces have > >>different drivers that do not know about each other. In that > >>case, interface drivers may simultaneously issue control messages, > >>and all but one will fail... > > Or even single-interface devices, where userspace programs > will for any reason talk to the devices using control messages. > Maybe vendor-specific requests that the generic in-kernel driver > doesn't know about. (We had that scenario for some modem option > settings, as I recall.) Yeah, lots of situations. > > Yeah, we need something. We've talked about this in the past, but we > > never came to a conclusion. > > > > We also need to provide some sort of resource locking too. We don't want > > 2 seperate applications trying to change some value via a control > > message, but we do want 2 different drivers to change the seperate > > interface parameters. > > Easily done by providing something like a semaphore to be used in > those rare cases it's needed. However, I don't recall anyone yet > coming up with a real example of such a resource ... that scenario > has been hypothetical so far. > > I'd rather keep such locking just as hypothetical: don't provide > hooks till we have devices+drivers that need them! :) There's the much discussed USB storage bulk/control problem which is a slightly different, but still related locking issue. How about we require driver level locking for interface level control requests? 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. If the driver is not loaded then you can do whatever you want. > > 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. There is a strong desire to keep bulk fast, but I can't come up with a reason for control to be faster. JE _______________________________________________________________ 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
