On Wed, 18 Aug 2010, Sarah Sharp wrote: > > There might be a problem if slot IDs get reused when you start reviving > > the devices under a controller that has been reset. The udev->slot_id > > value might point to another device's structure. > > xhci_discover_or_reset_device will have to check and make sure that the > > slot really does match the device. > > Would it be possible when the failed resume is detected to go through > the list of usb_devices that the xHCI driver has slots for, and change > the slot_id to -1? That would indicate the struct usb_device is valid, > but there is no slot for it. > > The slot_id field in struct usb_device is an int, although there are a > lot of places it's cast to a unsigned integer. Those places would have > to be looked at, but I suspect that xhci_check_args() would be the only > place that would need to be changed. Then the new > xhci_discover_or_reset_device() would need to check udev->slot_id for -1 > instead of checking whether xhci->devs[slot_id] is non-null. Sure, you could do that if you wanted. But IMO it would be easier to store a pointer back to the usb_device in the slot structure, and have xhci_discover_or_reset_device check that the pointer points to the right device. > I think I would rather the call to allocate a slot in usb_alloc_dev() > stay there. It really makes sense there, since the xHCI driver is > allocating a resource for the device, and you want any memory allocation > to fail early. I'd have to look at the hub init code to see whether > it's safe to wait until the device is reset to allocate the slot (and > even if it's reset in all cases, since I know I tried to skip USB 3.0 > device reset on an initial connect). There's not much difference between an initial connect and a reset following HC reinitialization. The code in hub_port_init needs to work correctly for both cases, i.e., whether or not the resource is already allocated. Still, there's nothing _wrong_ with keeping the call in usb_alloc_dev. 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
