> -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: Monday, July 26, 2010 11:06 PM > To: Xu, Andiry > Cc: sarah.a.sharp@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; > gregkh@xxxxxxx > Subject: Re: [PATCH 0/4 v5] xHCI: PM patchset > > On Mon, 26 Jul 2010, Andiry Xu wrote: > > > Hi Sarah, > > > > This is xHCI pm patchset v5. > > > > Changelog from v4: > > > > 1. Remove atomic operation in port pm and remote wakeup patch. > > 2. Refine xhci_cmd_ring_init() and xhci_event_ring_init(). > > 3. Free all virt devices if the xHC restore error and reset. > > 4. Remove redundant changes to xhci.h. > > 5. Some semantic refine. > > > > The patchset is based on your master branch, but I cannot enter S3 with > > 2.6.35-rc4, even with xhci-hcd unloaded. so I use 2.6.34 for test. > > > > I have tested port PM, remote wakeup and S3. I've tested USB3.0/2.0/1.1 > > device, plug in before/during S3 suspend and after S3 resume, and run S3 > > for several times. In most cases the devices will be recognized > > successfully and work fine. But there are some issues listed below. > > > > 1. Every time the system resume from S3, the STS_SRE bit is set, which > > indicates the xHC restore error, so the xHC should be reset. The hub > > driver will try to resume the devices, but it will found the devices > > lost and then free and re-initialize them. > > That's not quite right. It tries to reset the device first. Only if > the reset fails does it free and re-initialize the device. > > At least, that's what is supposed to happen. It might not work right > with USB-3. You may need to change the hub_activate() routine in > core/hub.c: Replace the line > > } else if (portstatus & USB_PORT_STAT_ENABLE) { > > with > > } else if ((portstatus & USB_PORT_STAT_ENABLE) && > type == HUB_RESUME) { > > > It will show "cannot reset > > HCD device state" in the dmesg. I'm not quite sure how to fix this. > > > > 2. If you plug an USB3.0 device before S3 suspend, After S3 resume, the > > device will failed to be recognized. To make it work, the disabling of > > USB3 port should be skipped, then the USB3.0 device will be initialized > > successfully and work properly. I think you already know about this. > > Since it's not related to PM, I did not include the skip disabling of > > USB3 port in the patchset. > > This is probably the reason you get those "cannot reset HCD device > state" errors. > > > 3. There is an issue related with plugin sequence when there are several > > char devices plugged in before S3 suspend. If first plug in a device to > > a port with bigger number (for example, port 4), then plug in a device > > to a port with smaller number (for example, port 2), the devices will be > > registered like this: > > > > Device Slot id port number /dev/char > > Dev1 Slot 1 port 4 189:897 > > Dev2 Slot 2 port 2 189:898 > > > > After resume, Dev2 on port 2 will be first resumed. Since the xHC is > > reset, the device resume will fail, Dev2 will be freed and > > re-initialized. Then it will fail in sysfs_add_one(), dmesg shows > > "sysfs: cannot create duplicate filename '/dev/char/189:897'", because > > the filename is still possessed by Dev1, and the initialization of Dev2 > > fails. Dev1 on port 1 will be resumed next and it will be initialized > > successfully. Check the dmesg attached. > > The reason for this is not clear. It may go away when the other > problems are fixed. > > > If you change the ports the two devices plug in, like this: > > > > Device Slot id port number /dev/char > > Dev1 Slot 1 port 2 189:897 > > Dev2 Slot 2 port 4 189:898 > > > > Then two devices will be re-initialized successfully. In this case, Dev1 > > will be freed and re-added as 189:897. no conflict happens and it goes > > well. > > > > I tried EHCI controller and found something different with xHCI: every > > time when I unplug a device and re-plug in to a EHCI USB2 port, the > > minor number of the device will increase. For example, plug in a USB2.0 > > HDD, it will appear as /dev/char/189:15; then unplug it and re-plug in, > > it will be /dev/char/189:16. But for xHCI port, it will always be the > > same. I've no idea what causes this difference, but it may causes the > > initialization fail in my case. Is this a bug? > > The minor number is constructed from the bus number and device address. > When you get a conflict, it's because the new device is assigned an > address already held by the old device. I don't know why this happens. > After check, I think I may found the difference between EHCI and xHCI in device address choosing. In EHCI, the hub driver calls choose_address() to set the device address. Choose_address() uses find_next_zero_bit() to find an available address. So the devnum will increase every time, because bus->devnum_next is increased every time. However, xHCI does not call choose_address(). The USB device address is assigned by H/W, upon a successful address device command. xHCI driver then set the devnum to the value xHC returns, so it will always be the same value. Thanks, Andiry -- 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
