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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Aug 2021 22:54:32 +0530 From: Sibi Sankar <sibis@...eaurora.org> To: Stephen Boyd <swboyd@...omium.org> Cc: Deepak Kumar Singh <deesin@...eaurora.org>, bjorn.andersson@...aro.org, clew@...eaurora.org, 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 On 2021-08-09 23:28, Stephen Boyd wrote: > 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. If the modem firmware crashes during suspend, the system comes out of xo-shutdown and AFAIK stays there until we handle the interrupt. > >> >> >> 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? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Powered by blists - more mailing lists