linux-kernel - Re: [PATCH] rpm: pm: enable PM_RPM

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: <CAOuDEK0NcijUKAL3fGtO=Ks+Y38TRhJcVx+ff-QUyUA0LcQ1Bw@mail.gmail.com>
Date:   Wed, 8 Nov 2023 16:45:43 +0800
From:   Guan-Yu Lin <guanyulin@...gle.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     gregkh@...uxfoundation.org, rafael@...nel.org, len.brown@...el.com,
        pavel@....cz, heikki.krogerus@...ux.intel.com, mkl@...gutronix.de,
        hadess@...ess.net, mailhol.vincent@...adoo.fr,
        ivan.orlov0322@...il.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        pumahsu@...gle.com, raychi@...gle.com, albertccwang@...gle.com
Subject: Re: [PATCH] rpm: pm: enable PM_RPM_EXCEPTION config flag

On Tue, Oct 31, 2023 at 10:39 PM Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Tue, Oct 31, 2023 at 05:38:55PM +0800, Guan-Yu Lin wrote:
> > Introducing PM_RPM_EXCEPTION config flag, which may alter the priority
> > between system power management and runtime power management. In
> > suspend-to-idle flow, PM core will suspend all devices to avoid device
>
> Your patch affects all forms of system suspend, not just
> suspend-to-idle.  What do you actually mean here?
>
> > interact with the system. However, chances are devices might be used by
> > other systems rather than a single system. In this case, PM core shouldn't
> > suspend the devices. One may use PM_RPM_EXCEPTION config flag to mark
> > such exception, and determine the power state of a device with runtime
> > power management rather than system power management.
>
> This sort of arrangement -- a device shared between two different
> systems -- could happen with any sort of device.  Why does your patch
> affect only USB devices?
>
> > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> > index 4b31629c5be4..beba7a0f3947 100644
> > --- a/kernel/power/Kconfig
> > +++ b/kernel/power/Kconfig
> > @@ -193,6 +193,14 @@ config PM
> >         responsible for the actual handling of device suspend requests and
> >         wake-up events.
> >
> > +config PM_RPM_EXCEPTION
> > +     bool "Prioritize Runtime Power Management more than Power Management"
>
> Runtime Power Management is a form of Power Management, so what you
> wrote doesn't make sense.  What you really meant is: Prioritize Runtime
> Power Management more than System Power Management.
>
> > +     default n
> > +     help
> > +     Provides a way to prioritize Runtime Power Management more than Power
> > +     Management. This way system can suspnd with maintaining specific
>
> s/suspnd/suspend/
> s/with/while/
>
> > +     components in operation.
>
> Your patch does not allow _specific_ components to be kept in operation.
> _All_ in-use components that support prioritized PM (with this patch,
> all USB components) will remain powered during system suspend, even if
> the user wants only _some_ of them to be kept powered.
>
> Alan Stern
>
> > +
> >  config PM_DEBUG
> >       bool "Power Management Debug Support"
> >       depends on PM
> > --
> > 2.42.0.820.g83a721a137-goog
> >

Thanks for the questions. Let me first introduce my motivation for
proposing this feature. We can discuss the implementation details later.

Motivation:
Currently, system PM operations always override runtime PM operations.
As runtime PM reflects the power status of devices, there is a
possibility that runtime PM states that a device is in use, but system
PM decides to suspend it. Up to now, we have assumed that a device can't
function without resources from the system, so the device should acquire
a wakelock to prevent this from happening. However, what if the device
does not need the system's support to function? Or only needs limited
resources (e.g., only limited power source or clock) to function? In this
situation, we would like to keep the device on but allow the system to
suspend. This is an example where we would like devices to follow runtime
PM rather than system PM.

Feature Supported:
1. Devices could control the priority of system PM and runtime PM during
   runtime.
2. The control should be at the device level, meaning that different
   devices should control their own priorities.

Goal of This Patch:
1. Design a framework to support features above.
2. Apply it into usb for demonstration.

Thanks,
Guan-Yu