> > > > > > > You may need both (glue & xhci), it depends on system design, and > > usually, these two kinds of wakeup setting isn't conflict. > > Ok, thanks. So if I understand correctly the onboard hub driver should check the > wakeup state of the xHCI to determine if remote wakeup is enabled for the > controller (after all it doesn't know anything about the platform device). > Wakeup might not work properly if it is disabled for the platform device, but it's > the responsability of the board software/config to make sure it is enabled > (possibly this could be done by making the dwc3-qcom driver understand the > 'wakeup-source' property, as the xhci-mtk driver does). No, every level should handle its own wakeup setting. You may have to do this since the USB bus and platform bus are two different buses, you should not visit device structure across the bus. And you don't need a device tree property to do it. For platform driver, you could use device_may_wakeup, for onboard hub power driver, you could use usb_wakeup_enabled_descendants since you need to cover descendants. The purpose of these two wakeup logic is different, for USB bus, it is used to tell USB devices to enable remote wakeup and do not power off its regulator; for platform bus, it is used to tell the controller to enable its wakeup setting and keep the regulator for its USB controller and USB PHY (if needed). Peter
