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] [day] [month] [year] [list]
Message-ID: <CAE-0n51XcRbY7UeU6bhrrnkvD7rboq3QZFw9Tu0xQZ6e1VyjRw@mail.gmail.com>
Date:   Mon, 13 Sep 2021 12:42:30 -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 V2 1/1] soc: qcom: smp2p: Add wakeup capability to SMP2P IRQ

Quoting Deepak Kumar Singh (2021-09-13 10:45:19)
>
> On 8/17/2021 1:53 AM, Stephen Boyd wrote:
> >> +       ret = device_init_wakeup(&pdev->dev, true);
> > I still wonder if it's better to leave this off by default and only
> > enable it if the kernel is using autosuspend (PM_AUTOSLEEP). Then
> > userspace is responsible to decide if it can handle the wakeup with the
> > screen off, reload the remoteproc, and go back to suspend if it isn't
> > using autosuspend.
>
> Seems like not all targets use PM_AUTOSLEEP feature, even those targets
> may require wakeup to handle
>
> modem crash so that important modem events are not missed. I think we
> can keep wake up as default behavior
>
> and let the user space disable it through sysfs if it doesn't want it as
> wake up source.

I don't understand. What if userspace is simple and doesn't use
autosleep and will turn the screen on when the kernel resumes? Why do we
expect the modem crashing and causing the screen to turn on to be a good
user experience?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ