> > Start with a rough description of what needs to change, > > then work up to proposals. > > So, I know what needs to change for to support USB 3.0 on the host-side, > but I'm not familiar with the gadget side of things. > > > Example, changes to <linux/usb/ch9.h> will cover both > > host and peripheral sides of the stack; mostly new or > > updated descriptors, but presumably also updating the > > device speed enumeration. That would likely go well > > as a single early patch. > > One new thing for USB 3.0 devices is the requirement for an endpoint > companion descriptor after every endpoint. You can see what sort of > information is in that descriptor by looking at section 9.6.7 of the USB > 3.0 bus spec. I have a patch to add the structure to > include/linux/usb/ch9.h and parse that descriptor on the host side. > Would the gadget size need more than that? Interfaces for the hardware to report its bMaxBurst capabilities, for the gadget stack to use them when autoconfiguring interfaces, and for the gadget stack to come up with new "SuperSpeed" config descriptors ... maybe more, too. I've done no more than skim those 3.0 bus specs; it looks from that level as if drivers can mostly treat data transfers as just being faster, and use the same I/O models. One exception being the new bulk "stream" capability, multiplexing different logical data flows on one endpoint. I'm not sure what to make of the notion of exposing data CRC errors ... that seems like something the peripheral (and host) controllers might not necessarily be exposing to upper layers of software. > There's also a new Binary Object Store descriptor required for USB 3.0 > devices (section 9.6.2.2). I don't have any patches that deal with > descriptor yet. David Vrabel said the wireless USB stack has some code > to parse the BOS descriptor. The new SuperSpeed USB Device Capability > BOS descriptor structure would still need to be added to > include/linux/usb/ch9.h. Right. And the composite gadget framework would need to provide some of those, possibly with non-generic input at the time device configurations are being assembled. > > The basic design problem here will be converting what > > comes out of the spec development process -- likely a > > "formats and protocols" level spec -- into updates for > > the Linux-USB stack. Is enumeration affected? How? > > 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. > 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. > > That could affect the hub and HCD interfaces. What > > (if anything) will interface and function drivers > > need to understand differently? > > There is a new hub descriptor for USB 3.0, new requests, and new state > machines for devices. I worked around these requirements by pretending > the xHCI USB 3.0 root hubs had a USB 2.0 descriptor with the speed > changed. So the xHCI driver won't work with external hubs yet. I think > there will need to be some changes made to khubd, but I haven't looked > at the hub state machines in a while. Unless hubs are visible to the peripherals, that's entirely a host side issue. > With the USB 3.0 bus spec, they tried to get rid of the polling of > interrupt endpoints. If a device doesn't have data, it can respond with > a NRDY (not ready) packet. The host will then wait for the device to > send a ERDY (endpoint ready) packet before communicating with that > endpoint again. There will be some gadget-side changes necessary for > this. I think the host-side changes are all taken care of in the > hardware, but I would have to check on that. Why would the gadget stack need to change? That seems like something the hardware should handle. The gadget driver will either have queued data, or not; NRDY gets sent if not, and then later ERDY. If the controller needs help, that's all in the hands of its driver -- invisible to upper layers. > > Stuff that percolates into usbcore deserves some > > discussion; ditto stuff affecting how e.g. composite > > gadgets get assembled. > > 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. I'm thinking the link power management should ideally not be visible outside the peripheral controller driver. - Dave > Those will both be > a requirement for USB 3.0 device compliance, but we can discuss those > after we have an idea of the changes necessary for basic USB 3.0 > gadget-side support. > > Can anyone think of any other changes for USB 3.0 gadget side support? > > Sarah Sharp > > -- 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
