On Mon, 3 Jan 2011, Sarah Sharp wrote: > > > The usb_hcd's state field is a similar mess. Sometimes the state applies > > > to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and > > > HC_STATE_QUIESCING. But sometimes the state refers to the roothub state: > > > HC_STATE_RESUMING and HC_STATE_SUSPENDED. > > > > I'm not sure this distinction makes any sense. But in any case, it > > certainly is true that hcd->state is a terrible mess. > > I had thought that HC_STATE_SUSPENDED referred to when the usb_bus was > suspended. Now that either bus under the xHCI host can be suspended, > HC_STATE_RESUMING and HC_STATE_SUSPENDED doesn't make sense when applied > to a usb_hcd, only to a specific usb_bus. Look at how hcd->state is used in hcd.c and hcd-pci.c. I believe most of the usages refer to the bus, not the controller. One thing we will have to worry about is usb_hc_died(). When anything goes wrong with an xHCI controller, both buses have to be stopped. In the end, it may be necessary for xhci-hcd to take care of this directly. > > > This poses an issue with the xHCI split roothub, where two buses are > > > registered for one PCI device. Each bus in the xHCI split roothub can be > > > suspended separately, but both buses must be suspended before the PCI > > > device can be suspended. Therefore, make sure that the USB core checks > > > hcd->state equals HC_STATE_SUSPENDED for both roothubs before suspending > > > the PCI host. > > > > This is tricky. Normally both buses will indeed be suspended before > > the controller; the only situation where that wouldn't be true is if a > > remote wakeup races with the controller suspend. I wonder if we can't > > detect these races in a better way. > > Hmm, interesting. I don't have any ideas currently about that; I would > have to look at the code. I can't think of any simple way to do it, offhand. But since it's only an optimization, we don't _need_ to do it at all. 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
