On Wed, Aug 18, 2010 at 10:27:00AM -0400, Alan Stern wrote: > On Wed, 18 Aug 2010, Xu, Andiry wrote: > > > To remove alloc_dev method calling in usb_alloc_dev(), two more places > > need to be modified: xhci_check_args() in > > xhci_discover_or_reset_device(), to allow udev with slot_id = 0 to be > > allocate; and reset super speed device in hub_port_init(). I tried and > > it seems work fine. But I wonder if there will be any potential issue, > > especially xhci_discover_or_reset_device() uses udev->slot_id to > > allocate or reset device. Will there be any udev->slot_id conflict issue > > in certain cases? Sarah, what's your opinion? > > 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. 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). 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
