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: <CAJZ5v0h7PeqXXtj0J=JaBJkuMTvKXXOCN3xL5Omu6vej_vWCwg@mail.gmail.com>
Date:   Thu, 18 Mar 2021 19:40:59 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        Lina Iyer <ilina@...eaurora.org>,
        Kevin Hilman <khilman@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Heiko Stuebner <heiko@...ech.de>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PM: domains: Don't runtime resume devices at genpd_prepare()

On Thu, Mar 4, 2021 at 8:30 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> Runtime resuming a device upfront in the genpd_prepare() callback, to check
> if there is a wakeup pending for it, seems like an unnecessary thing to do.
> The PM core already manages these kind of things in a common way in
> __device_suspend(), via calling pm_runtime_barrier() and
> pm_wakeup_pending().
>
> Therefore, let's simply drop this behaviour from genpd_prepare().
>
> Note that, this change is applicable only for devices that are attached to
> a genpd that has the GENPD_FLAG_ACTIVE_WAKEUP set (Renesas, Mediatek, and
> Rockchip platforms). Moreover, a driver that needs to restore power for its
> device to re-configure it for a system wakeup, may still call
> pm_runtime_get_sync(), for example, to do this.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> ---
>  drivers/base/power/domain.c | 36 ------------------------------------
>  1 file changed, 36 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 78c310d3179d..b6a782c31613 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1087,34 +1087,6 @@ static void genpd_sync_power_on(struct generic_pm_domain *genpd, bool use_lock,
>         genpd->status = GENPD_STATE_ON;
>  }
>
> -/**
> - * resume_needed - Check whether to resume a device before system suspend.
> - * @dev: Device to check.
> - * @genpd: PM domain the device belongs to.
> - *
> - * There are two cases in which a device that can wake up the system from sleep
> - * states should be resumed by genpd_prepare(): (1) if the device is enabled
> - * to wake up the system and it has to remain active for this purpose while the
> - * system is in the sleep state and (2) if the device is not enabled to wake up
> - * the system from sleep states and it generally doesn't generate wakeup signals
> - * by itself (those signals are generated on its behalf by other parts of the
> - * system).  In the latter case it may be necessary to reconfigure the device's
> - * wakeup settings during system suspend, because it may have been set up to
> - * signal remote wakeup from the system's working state as needed by runtime PM.
> - * Return 'true' in either of the above cases.
> - */
> -static bool resume_needed(struct device *dev,
> -                         const struct generic_pm_domain *genpd)
> -{
> -       bool active_wakeup;
> -
> -       if (!device_can_wakeup(dev))
> -               return false;
> -
> -       active_wakeup = genpd_is_active_wakeup(genpd);
> -       return device_may_wakeup(dev) ? active_wakeup : !active_wakeup;
> -}
> -
>  /**
>   * genpd_prepare - Start power transition of a device in a PM domain.
>   * @dev: Device to start the transition of.
> @@ -1135,14 +1107,6 @@ static int genpd_prepare(struct device *dev)
>         if (IS_ERR(genpd))
>                 return -EINVAL;
>
> -       /*
> -        * If a wakeup request is pending for the device, it should be woken up
> -        * at this point and a system wakeup event should be reported if it's
> -        * set up to wake up the system from sleep states.
> -        */
> -       if (resume_needed(dev, genpd))
> -               pm_runtime_resume(dev);
> -
>         genpd_lock(genpd);
>
>         if (genpd->prepared_count++ == 0)
> --

Applied as 5.13 material, thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ