On Mon, 27 Sep 2010, Sarah Sharp wrote: > On Mon, Sep 27, 2010 at 11:51:44AM -0400, Alan Stern wrote: > > On Mon, 27 Sep 2010, Sarah Sharp wrote: > > > Then we're stuck with a device in one alt setting, and the USB core and > > > xHC in a different alt setting. So I think we need a shared bandwidth > > > lock for the whole xHCI host controller. > > > > You know, I'm not so sure a shared lock will work -- not even in the > > form we're using now. Consider this variant scenario: > > > > 1. The class driver wants to switch a USB 2.0 to a different alt > > setting, perhaps with fewer endpoints. The xHCI Configure Endpoint > > command succeeds, freeing some internal resources. > > > > 2. An URB is submitted for some other device entirely, consuming some > > of the internal resources. > > The xHCI host controller guarantees that all resources (bandwidth and > internal) for a given configuration are available when the Configure > Endpoint command is successfully completed. Issuing URBs and putting > things on the endpoint rings should not change internal resources. > Section 4.6.6 is explicit about the host controller needing to keep > global bandwidth and resources available varies that only change when a > configure endpoint, evaluate context, reset device, or disable slot > command happens. Okay, then suppose one of those other commands occurs at a bad time. > > This is beginning to sound sufficiently difficult that it ought to be > > addressed officially. Can you bring this up before the USB-IF or ask > > somebody there at Intel? How does one change between alternate > > settings in a way that is guaranteed to backtrack successfully if the > > device refuses the change? > > I tried to get the xHCI spec architect to put something more concrete > into the spec, but my suggestion didn't make it into the 0.96 spec. I > can redig those conversations out of my mail archives, but changing the > spec now isn't going to change the hardware that's already out there. I > can probably get the USB-IF compliance team to add a test that simply > switches back and forth between two alternate settings or configs, but I > don't think a spec change is very likely at this point. :( How about simply asking the best way to do this? > > The bandwidth and bus addresses don't really concern the OS because > > they are all handled internally by the xHCI hardware. To what extent > > would the USB core need to know that each port has its own bus? > > True, the USB core probably doesn't need to know about the separate > buses. It might be useful to speed up the enumeration process, since > you could have multiple devices at address 0 under an xHCI host with > such a configuration. I'm not inclined to worry about that at the moment. Especially since we currently have a single, global usb_address0_mutex instead of separate mutexes for each bus. Alan Stern -- 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
