On Wed, 7 Aug 2013, Huang Rui wrote: > > > Could you explain that how can you make sure the root cause is unable > > > to relay wakup requests from downstream port to upstream port if > > > downstream port's suspend feature is not set? The OS is unable wakeup > > > from S3 at that time. We can't fetch dmesg log and serial port is > > > suspend either at that time. Did you use any other tools to trace this > > > issue? Could you teach me? Actually, I was encoutered this issue > > > either. > > > > It was simple. I ran two tests. They were exactly the same, except > > that the suspend feature was set in the first test and was not set in > > the second test. Remote wakeup worked in the first test and not in the > > second. > > > > Got it, but I'm still a little confused. For example, one mouse is > attached at usb2.0 port of roothub, and it supports remote wakeup. But > the wakeup attribute is disabled for mouse defaultly, am I right? So Yes. > remote wakeup doesn't work on this mouse, then run system suspend into > s3 with "global suspend"(don't send Set Suspend Feature request). In > this case, remote wakeup and global suspend doesn't mix, am I right? No. In this case they do mix okay. > But system still can not wake up normally. In this case, the system is not supposed to wake up when you press a mouse button, because the mouse is disabled for remote wakeup. Therefore the system behaves correctly. Instead of a mouse, consider a USB keyboard. Keyboards _are_ enabled for remote wakeup by default. And suppose the keyboard is plugged into an external hub, not the root hub. Then pressing a key on the keyboard _should_ cause the system to wake up from S3. But with some hubs, if you use global suspend then pressing a key does not wake up the system. 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
