On Mon, Jan 26, 2009 at 03:13:31PM -0800, David Brownell wrote: > > There are enumeration changes for USB 3.0 devices, but I think much of > > it is taken care of by the PHY. One interesting thing to note is that > > USB 3.0 devices in a tree structure are reset and link trained in > > parallel by the PHY. > > So users would need to handle more than the usual number of > function-level reset/reinitialize events? Currently those > events are rare ... and only stateless devices/drivers manage > to avoid presenting them to users. I'm not sure what you mean by "users". Gadget drivers? I don't think there will be more reset events. I just don't know if there's state in the gadget framework for it to expect a specific enumeration sequence. A pointer to code that does that would be helpful. :) > > By the time the OS receives the port status change notification, all USB > > 3.0 devices below that root port are all at address 0. So there is no > > need for the OS to reset them. The OS addresses USB 3.0 devices by > > using a route string (you can see an example of this in section 10.1.3.2 > > of the USB 3.0 bus spec). > > > > I have host-side code that modifies the host-side enumeration sequence > > to take care of this. I'm not sure how much new gadget side support is > > needed. Ideas? > > Any reason they shouldn't be treated just like a standard > reset event? Including re-initializing from scratch, based > on what the host tells them to do. Why reset them again? I have code that just skips the device reset when the host controller driver reports a connect on a USB 3.0 port. The real reason the parallel link training went it was because Microsoft really wanted a fast boot from a USB hard drive deep in the device tree. Why they wanted that is a mystery to me, but they pushed very hard for it. I don't see any reason not to take advantage of that change, unless we find devices that don't work because of that. I hope we don't. > > > That could affect the hub and HCD interfaces. What > > > (if anything) will interface and function drivers > > > need to understand differently? I didn't need to change the HCD interfaces at all. I did need to change khubd code to not reset the USB 3.0 device. The code seems to be working on the prototype USB 3.0 device I have. (Having more prototypes to test on would be wonderful too.) > > Of course these changes discussed don't even cover the new link power > > management and function suspend for USB 3.0 devices. > > My quick glance suggests that "function suspend" may be a > misnomer, since it's an *interface* feature flag ... while > functions are not limited to single interfaces. "Function" is an officially defined term now. A USB device function is all the interfaces described by an interface association descriptor. So a function can include multiple interfaces. The idea was to suspend pieces of the USB device while keeping the device as a whole functional. The OS might want to ask the USB printer gadget to power down its scanner interfaces if no device driver has claimed those interfaces. If all device drivers unclaimed all interfaces of a USB device, then the host OS should put the device into the selective suspend state (U3) as it does now. (Putting all the functions into function suspend does not automatically put the device into U3.) So there probably needs to be gadget interfaces similar to what it does for selective (device) suspend. Sarah -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
