On Wed, 6 Jun 2018, Anshuman Gupta wrote: > On Wed, Jun 06, 2018 at 09:49:59AM -0400, Alan Stern wrote: > > On Wed, 6 Jun 2018, Anshuman Gupta wrote: > > > > > > > > In any case, when the system wakes up because of a signal received by a > > > > > > USB host controller, there should be a wakeup event associated with the > > > > > > host controller. Don't you get those events? > > > Yes we are getting those PM events but not consistently after debugging > > > I came to know that we are getting these host controller PM wakeup events, > > > but these events are only generated for newly plugged-in device. > > > > That is very strange. If the system is suspended, and a keypress on a > > USB keyboard (for example) causes the system to wake up, then > > pm_wakeup_event() _should_ be called for the host controller. > > > > If it isn't getting called then there might be a bug in the ACPI > > subsystem. I have CC'ed Rafael and the Linux PM mailing list, perhaps > > they can help track this down. > > > > Can you post the output from "lspci -vv" for your xHCI host controller? > Here below "lspci -vv" output for xhci host controller. > > 00:14.0 USB controller: Intel Corporation Device 9d2f (rev 21) (prog-if 30 [XHCI]) > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Interrupt: pin A routed to IRQ 274 > Region 0: Memory at d1500000 (64-bit, non-prefetchable) [size=64K] > Capabilities: [70] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+) > Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ > Address: 00000000fee0f00c Data: 4142 > Kernel driver in use: xhci_hcd Okay, like I thought, this controller uses PCI PME# signals for power management. When the controller receives a wakeup request from a USB device and causes the system to resume from a sleep state, the ACPI code in the kernel should call pm_wakeup_event(). But you say this doesn't happen. Maybe the PM people can tell us what's going wrong; I am not familiar with the ACPI subsystem. > > It's also worth noting that by default, USB host controllers are set up > > so that plugging in or unplugging a device will not wake up the system, > > but a wakeup request received from a device will. I wonder why your > > system does not behave this way. What is the power/wakeup setting for > > your root hub? > Wakeup settings for host controller and root hub. > "localhost ~ # cat /sys/bus/pci/devices/0000\:00\:14.0/power/wakeup > enabled" > > "localhost ~ # cat /sys/bus/usb/devices/usb1/power/wakeup > disabled" That's normal. It means that plug and unplug events should not cause the system to wake up, but requests from attached USB devices should. > > > Will it be OK to send this patch for review, if you don't have any specific > > > concern. > > > > First I want to clear up this issue about wakeup events not being > > reported for host controllers. Once that is working correctly you may > > not even need the patch. > Still chrome os require the port usb_dev which caused the wakeup, so i think we > may require this patch. All right, I will add the change you requested to the patch and submit it for review. > > Alan Stern > > > > PS: I noticed that your email messages (other than the first one in > > this thread) are getting delivered to me but not to the linux-usb > > mailing list. Do you have any idea why that is? Can you fix it? > I will look for this problem, if it is due to any settings in my mutt > client but i can see this thread in mailing list. > https://www.spinics.net/lists/linux-usb/msg169751.html That URL points to a message I posted. Try to find the messages which _you_ posted on that archive site, for example by looking at: https://www.spinics.net/lists/linux-usb/index.html#169302 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
