> -----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. > Yes, you are right, I didn't make it clearly. The hub driver will try to reset the device first. After several failures, it will assume the device is gone, then free and re-initialize the device. The hub driver will call hcd->driver->reset_device() to reset the device. Reset Device is a xHCI command to put a device in addressed or configured state into default state. However since the xHC is reset, the reset command will fail - all the slots are freed and disabled after xHC reset. The command failure will show "cannot reset HCD device state" messages. > 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. > I've tested multiple devices behind an external hub. In this case the re-initialization will not fail, regardless of the plugin sequence. That's because during resume, the external hub will disconnect and all devices on the hub will be freed. The devices are re-initialized later. It will not cause any conflict because all the addresses are free now. For devices connected to root hub, one device will be freed and re-initialized, then another device. It the first device wants to require an address which is still possessed by the second device, its initialization will fail. 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
