linux-kernel - Re: [PATCH V1 1/1] soc: qcom: smp2p: Add wakeup capability to SMP2P IRQ

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]

Message-ID: <CAE-0n53ojhs+RMpsYtVjsrYbb_PRdkJOvxFhiTtJPMUDuoP_eA@mail.gmail.com>
Date:   Mon, 9 Aug 2021 10:58:34 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Deepak Kumar Singh <deesin@...eaurora.org>,
        bjorn.andersson@...aro.org, clew@...eaurora.org,
        sibis@...eaurora.org
Cc:     linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, Andy Gross <agross@...nel.org>
Subject: Re: [PATCH V1 1/1] soc: qcom: smp2p: Add wakeup capability to SMP2P IRQ

Quoting Deepak Kumar Singh (2021-08-09 04:05:08)
>
> On 8/6/2021 1:10 AM, Stephen Boyd wrote:
> > Quoting Deepak Kumar Singh (2021-08-05 09:17:33)
> >> Some use cases require SMP2P interrupts to wake up the host
> >> from suspend.
> > Please elaborate on this point so we understand what sort of scenarios
> > want to wakeup from suspend.
>
> Once such scenario is where WiFi/modem crashes and notifies crash to
> local host through smp2p
>
> if local host is in suspend it should wake up to handle the crash and
> reboot the WiFi/modem.

Does anything go wrong if the firmware crashes during suspend and the
local host doesn't handle it until it wakes for some other reason? I'd
like to understand if the crash handling can be delayed/combined with
another wakeup.

>
> >> Mark smp2p interrupt as wakeup capable to abort
> >> the suspend.
> >>
> >> Signed-off-by: Deepak Kumar Singh <deesin@...eaurora.org>
> >> ---
> >>   drivers/soc/qcom/smp2p.c | 11 +++++++++++
> >>   1 file changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c
> >> index 2df4883..f8659b0 100644
> >> --- a/drivers/soc/qcom/smp2p.c
> >> +++ b/drivers/soc/qcom/smp2p.c
> >> @@ -18,6 +18,7 @@
> >>   #include <linux/soc/qcom/smem.h>
> >>   #include <linux/soc/qcom/smem_state.h>
> >>   #include <linux/spinlock.h>
> >> +#include <linux/pm_wakeirq.h>
> >>
> >>   /*
> >>    * The Shared Memory Point to Point (SMP2P) protocol facilitates communication
> >> @@ -538,9 +539,19 @@ static int qcom_smp2p_probe(struct platform_device *pdev)
> >>                  goto unwind_interfaces;
> >>          }
> >>
> >> +       ret = device_init_wakeup(&pdev->dev, true);
> > Is smp2p supposed to wake up the device by default? If not, then this
> > should be device_set_wakeup_capable() instead so that userspace can
> > decide if it wants to get the wakeup.
> yes, we want smp2p to be wake up capable by default.

Why?