lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 03 May 2021 14:20:23 +0300
From:   Felipe Balbi <balbi@...nel.org>
To:     Sandeep Maheswaram <sanm@...eaurora.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>
Cc:     linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, Manu Gautam <mgautam@...eaurora.org>
Subject: Re: [PATCH v7 2/5] usb: dwc3: core: Host wake up support from
 system suspend


Hi,

Sandeep Maheswaram <sanm@...eaurora.org> writes:
>> Sandeep Maheswaram <sanm@...eaurora.org> writes:
>>> Avoiding phy powerdown when wakeup capable devices are connected
>>> by checking phy_power_off flag.
>>> Phy should be on to wake up the device from suspend using wakeup capable
>>> devices such as keyboard and mouse.
>>>
>>> Signed-off-by: Sandeep Maheswaram <sanm@...eaurora.org>
>>> Reviewed-by: Matthias Kaehlcke <mka@...omium.org>
>>> ---
>>>   drivers/usb/dwc3/core.c | 7 +++++--
>>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index b6e53d8..bb414c3 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -1738,7 +1738,7 @@ static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg)
>>>   		dwc3_core_exit(dwc);
>>>   		break;
>>>   	case DWC3_GCTL_PRTCAP_HOST:
>>> -		if (!PMSG_IS_AUTO(msg)) {
>>> +		if (!PMSG_IS_AUTO(msg) && dwc->phy_power_off) {
>> should be able to detect this generically, no? Shouldn't
>> device_may_wakeup() be valid here and give you the answer you want?
>
> I thinkĀ  device_may_wakeup() gives whether the controller is wake up 
> capable or not.

Yes, but it's a bit more than that. Looking at devices.rst we read:

If :c:func:`device_may_wakeup(dev)` returns ``true``, the device should be
prepared for generating hardware wakeup signals to trigger a system wakeup event
when the system is in the sleep state.  For example, :c:func:`enable_irq_wake()`
might identify GPIO signals hooked up to a switch or other external hardware,
and :c:func:`pci_enable_wake()` does something similar for the PCI PME signal.

So, if there is a condition where $this device has to, somehow, deal
with wakeup, it should be configured accordingly. This ->phy_power_off
flag is telling us the same thing.

> But we want to keep phy powered on only when some wakeup capable devices 
> (eg:keyboard ,mouse ) are connected to controller.

Understood, it could be that we're missing some method for propagating
that state (i.e. keyboard with PM support) up to the parent device, but
that's no excuse to bypass driver boundaries. Wouldn't you agree?

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (512 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ