On Tue, 10 Aug 2010, Sarah Sharp wrote: > > > > I guess I don't understand what the issue is with the special case in > > > > hub_port_init(). I thought the real issue was that the xHCI host > > > > controller is has been reset and has lost its memory about any devices > > > > that the USB core has allocated. > > > > > > > > > > Hmm...I think so. xHCI driver allocates memory for each device to > > > reflect its state and other information. If xHC is reset, these memories > > > are still there, but their data is totally invalid. In the end these > > > memories will be freed and re-allocated when devices are re-initialized. > > > > That's the problem Andiry encountered, but it's only a symptom of a > > deeper problem. The deeper problem is that the kernel and the hardware > > have differing notions about whether or not a device exists, and that > > difference will lead to trouble. > > > > In hub_port_init the kernel believes there is a device attached to the > > specified port. If the xHCI controller doesn't (e.g., if it has just > > been reset), then it needs to be told to find out at this point. > > However usbcore doesn't know what the controller hardware believes, so > > the test and corresponding action must be carried out within xhci-hcd. > > Should the driver be looking at the port status bits for the devices > connected at the roothub during this call to xhci_reset_device()? If > the USB core believes the device is there (because it was before the > host suspended), but the device isn't there, will that be detected by > the USB core? Or is that the host controller's job? The core reads the port status before resetting the port during reset-resume, and if no device is connected it will know to skip the resume. Of course, the device could get unplugged between the port-status read and the reset. And the core doesn't check the port status before resets in other contexts. The answer to your question is that the root hub should behave like an external hub. What does a USB-3.0 hub do if you tell it to reset a port when no device is plugged in? In USB-2.0 the hub does nothing; that would be good enough. > > The conclusion is that Andiry's suggestion was correct. In addition to > > invoking the address_device callback, hub_set_address should also call > > update_address. Or to put it another way, the call to update_address > > in hub_set_address should be moved outside the "else" clause, down next > > to the usb_set_device_state call. And xhci_address_device shouldn't > > store the actual hardware address in the device structure; it should > > keep that information private. > > Yeah, you're probably right that slot_id shouldn't be in the usb_device. > But the driver needs some way to turn the usb_device into a slot ID, > even when there aren't URBs involved. Do you have any suggestions for > keeping track of this? WUSB does something similar by stashing the > wusb_dev in the usb_device structure. Would you make a similar argument > about that variable? As far as I'm concerned, you can rename wusb_dev to hw_dev or something like that, and then share it between wusb and xHCI (make it a void *). I don't know how the wusb core and drivers work. If they have a similar problem about not resetting a device they aren't aware of, then they should be changed in the same way. 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
