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]
Date:   Sun, 31 Dec 2017 12:47:58 +0100
From:   "Rafael J. Wysocki" <>
To:     Geert Uytterhoeven <>
Cc:     "Rafael J. Wysocki" <>,
        Ulf Hansson <>,
        Geert Uytterhoeven <>,
        Linux PM <>,
        Thomas Gleixner <>,
        Jason Cooper <>,
        Marc Zyngier <>,
        Linus Walleij <>,
        Simon Horman <>,
        Niklas Soderlund <>,
        Linux-Renesas <>,,
        Linux Kernel Mailing List <>
Subject: Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

On Sun, Dec 31, 2017 at 10:22 AM, Geert Uytterhoeven
<> wrote:
> Hi Rafael,
> On Sun, Dec 31, 2017 at 1:56 AM, Rafael J. Wysocki <> wrote:
>> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson <> wrote:
>>> From: Geert Uytterhoeven <>
>>> Changes in v2: [By Ulf Hansson]
>>>         - I have picked up the series from Geert [1] and converted it into use
>>>         the WAKEUP_PATH driver PM flag. This includes some minor changes to each
>>>         patch and updates to the changelogs.
>>>         - An important note, the WAKEUP_PATH driver PM flag is introduced in a
>>>         separate series [2], not yet applied, so @subject series depends on it.
>>>         - One more note, two of the patches has a checkpatch error, however I
>>>         did not fix them, becuase I think that should be done separate.
>>> [1]
>>> [2]
>>> More information below, picked from Geert's previous cover letter.
>>> Kind regards
>>> Uffe
>>> Hi all,
>>> If an interrupt controller in a Renesas ARM SoC is part of a Clock
>>> Domain, and it is part of the wakeup path, it must be kept active during
>>> system suspend.
>>> Currently this is handled in all interrupt controller drivers by
>>> explicitly increasing the use count of the module clock when the device
>>> is part of the wakeup path.  However, this explicit clock handling is
>>> merely a workaround for a failure to properly communicate wakeup
>>> information to the device core.
>>> Hence this series fixes the affected drivers by setting the devices'
>>> power.wakeup_path fields instead, to indicate they are part of the
>>> wakeup path.  Depending on the PM Domain's active_wakeup configuration,
>>> the genpd core code will keep the device enabled (and the clock running)
>>> during system suspend when needed.
>> However, there is a convention, documented in the kerneldoc comment of
>> device_init_wakeup(), by which devices participating in system wakeup
>> "passively" (like USB controllers and hubs) are expected to have it
>> enabled by default.
>> If that convention was followed by the devices in question here, the
>> wakeup_path bit would be set for them and no other code changes would
>> be necessary.  So is there any reason for not following it?
> Yes there is.  The need to stay enabled during system suspend depends
> on the consumer of the interrupt. It is controlled by the consumer using
> the irq_chip.irq_set_wake() callback at runtime, and may change at runtime.
> If the wakeup_path flag is always set, the interrupt controller will
> never be suspended during system suspend, and thus waste power.


For IRQ chips in particular, I think, you don't need add new fields to
struct dev_pm_info to make it work.

In ->suspend (or ->suspend_late, which may be better) you can check
the IRQD_WAKEUP_STATE flag of the irq_desc associated with the pin.
If that is set, you can simply set power.wakeup_path for the device
and that will make genpd skip it.  Wouldn't that work?


Powered by blists - more mailing lists