On 20-07-06 12:22:37, Alan Stern wrote: > On Mon, Jul 06, 2020 at 04:03:08AM +0000, Peter Chen wrote: > > > > Thanks for the information, Alan. > > > > > > > > I could not understand why device_wakeup_enable is used in these > > > > device drivers? At Documentation/driver-api/pm/devices.rst, L189, it also says: > > > > > > > > during a system sleep transition. Device drivers, however, are > > > > not expected to call :c:func:`device_set_wakeup_enable()` directly > > > > in any case. > > > > > > It also says: > > > > > > It should also default to "enabled" for devices that don't > > > generate wakeup requests on their own but merely forward wakeup > > > requests from one bus to another (like PCI Express ports). > > > > > > The controller device falls into this category. It doesn't generate wakeup requests > > > on its own; it merely forwards wakeup requests from the root hub or USB devices. I > > > think the intention was that drivers for these devices would call device_init_wakeup() > > > instead of calling both > > > device_set_wakeup_capable() and device_wakeup_enable(). > > > > > > In any case, the rule about setting the default value is more important than the rule > > > about not calling device_set_wakeup_enable() directly. > > > > > > If you're concerned about connect-detect or disconnect-detect wakeup signals, > > > these are supposed to be enabled or disabled by the root hub's wakeup setting. > > > The idea is that root hubs should behave the same as external hubs -- and whether > > > or not an external hub generates a wakeup request when a connect or disconnect > > > event occurs is controlled by the hub's wakeup setting. > > > > > > > So, you suggest: > > At hcd-pci.c, ohci-platform.c, ehci-platform.c, and xhci-plat.c: > > change device_wakeup_enable to device_init_wakeup(dev, true). > > I don't think it's necessary to do that. > > device_init_wakeup(dev, true) just calls device_set_wakeup_capable() and > device_wakeup_enable(). The kernel already does the > device_set_wakeup_capable() part for these devices in the code that > registers them. For instance, the PCI core calls > device_set_wakeup_capable() when a new device is discovered and > registered, so there's no need for hcd-pci.c to repeat this action. But, that's not all the use cases. There are still two other use cases: (Taking xhci-plat.c as an example): - It is a platform bus device created by platform bus driver - It is a platform bus device created by glue layer parents (eg, dwc3/cdns3), usually, it is dual-role controller. > > > For xhci_suspend, use both controller's wakeup setting and roothub wakeup setting to > > judge if connect or disconnect wakeup needs to enable or not, like function ehci_adjust_port_wakeup_flags. > > Yes, something like that. This probably should be done in any case. > Some hardware might not like it if port-level connect/disconnect wakeups > are enabled but the controller-level wakeup signal is disabled. > > > > If the controller's wakeup setting defaulted to "disabled", then anybody who wanted > > > to get USB wakeup requests would have to enable them on both the USB device > > > and the controller. This would confuse users and cause problems. > > > > > > > I think if controller's wakeup setting is only used for ehci or xhci common code, that's ok. If > > it is also used for glue layer's power control and wakeup setting; it may need to set "disabled" > > for default value. > > What sort of wakeup events can the glue layer generate? It seems to me > that if there is no controller driver bound to the controller device > then the controller shouldn't be able to wake the system up in any case. It should be the similar with PCI device you mentioned below. The glue layer device is a platform device which is the parent of controller device, it could detect ID/VBUS/DP/DM/RX changes and generate wakeup events, these wakeup events will trigger interrupt, this interrupt number could be the same with controller interrupt number or not. When the system is in suspend (D3), when the wakeup events occurs, the system interrupt controller could trigger wakeup request, and wake system up. When the system is in full-power state (D0), this interrupt just wakes up glue layer, and glue layer wakes up common USB stack (EHCI/XHCI). > > > I am curious how PCI USB at PC determine whether it responds USB wakeup events or not? > > At Linux kernel or BIOS? It has two places for enabling USB wakeup, one for USB devices > > (including roothub), another is for PCI device? > > PCI devices send wakeup requests via a special PCI power management > signal called PME -- you can see its state in the output from "lspci > -vv" in the Power Management Capability section. In legacy systems this > signal was handled by the BIOS, but nowadays the PCI and ACPI subsystems > in the Linux kernel handle it. > > If a PCI host controller is in the D3 low-power state when a wakeup > event occurs, it uses the PME# signal to request a wakeup. If it is in > the D0 full-power state when a wakeup event occurs, it uses its normal > IRQ signal to tell the system about the event. > If the USBCMD.RS is cleared, does the interrupt could still occur when the system is at D0, or this interrupt is not USB interrupt, it is a PCI interrupt? -- Thanks, Peter Chen
