On Tuesday 27 January 2009, Sarah Sharp wrote: > 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 mean people ... who are trying to use the USB device for whatever, and would probably believe you if you said there was a specification for USB (but wouldn't read it). > 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. :) drivers/usb/gadget/*[hc] ... ;) There's no expectation about any sequence there, beyond what the USB spec requires. All I was pointing out is that a USB reset is supposed to scrub all session level state, which can be very user-visible. Example: you're streaming audio to your speakers ... there will be at least a dropout during the reset/re-enumeration sequence. > > > 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. Does this only apply to a sub-tree that's being newly connected? You said earlier that it applies to the whole tree. As in, the whole tree re-enumerates whenever you plug in one more device... > > > 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. I didn't say "again". You did say they were at address 0, which means they all got some kind of reset. If that's only for "new" devices, no problem; but you said it applies to the whole tree (which includes devices that were already enumerated, in other branches; not just the new branch). > 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. I suspect you elided some important details, like what you meant by "tree" maybe being more like just a new branch not the whole tree. Re "why they wanted that" -- faster boot time is a win for everyone, and needing device-at-a-time reset sequences for USB is a measurable slowdown. > > > > 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.) Especially ones that can implement arbitrary Linux-USB gadgets. ;) > > > 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. I suppose using an IAD was necessary, especially if the OS equivalent of "usbcore" wasn't going to understand things like CDC Union descriptors, and less-standard analogues. > 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. Wouldn't it suffice to guarantee that the interfaces receive the set_feature request for function suspend, using the existing setup() mechanism? - Dave -- 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
