On Tue, Aug 06, 2013 at 01:05:40PM -0400, Alan Stern wrote: > 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. > For end user, the keyboard connects to roothub directly and connects to intermediate hub (then connects to roothub) may not be different, since the hub may solder at the board directly. What the end user sees is the standard A USB port. -- Best Regards, Peter Chen -- 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
