On Thu, May 05, 2022 at 02:26:09PM +0530, Krishna Kurapati wrote:
> device_wakeup_path() tells if any of the children devices needs
> wakeup. Use this hint to enable/disable wakeup of our device. This
> helps the parent device of xhci-plat (like sysdev) to retrieve
> the wakeup setting via device_wakeup_path().
>
> Signed-off-by: Krishna Kurapati <quic_kriskura@xxxxxxxxxxx>
> ---
> drivers/usb/host/xhci-plat.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 649ffd8..ad585fa 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -415,6 +415,14 @@ static int __maybe_unused xhci_plat_suspend(struct device *dev)
> if (pm_runtime_suspended(dev))
> pm_runtime_resume(dev);
>
> + if (device_wakeup_path(dev)) {
> + if (!device_may_wakeup(dev))
> + device_wakeup_enable(dev);
> + } else {
> + if (device_may_wakeup(dev))
> + device_wakeup_disable(dev);
> + }
This code is not self-explantatory and deserves a comment.
Enabling/disabling wakeup for the purpose if signalling is a bit of a
hack. It might be an acceptable hack as long as it has no side effects.
However with the current implementation the wakeup state of the xHCI can
be different after resuming than it was before going to suspend:
after boot
grep -h xhci /sys/class/wakeup/*/name
=> xhci-hcd.14.auto
after suspend w/o wakeup capable device
grep -h xhci /sys/class/wakeup/*/name
=> no results
after suspend with wakeup capable device
grep -h xhci /sys/class/wakeup/*/name
=> xhci-hcd.14.auto
The hack shouldn't alter the wakeup state 'persistently', i.e. you'll have
to restore it on resume, as in Pavan does in his reply to '[PATCH v14 2/7]
PM / wakeup: Add device_children_wakeup_capable()' (it needs to be done
conditionally though).
