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 01:56:20 +0100
From:   "Rafael J. Wysocki" <>
To:     Ulf Hansson <>,
        Geert Uytterhoeven <>
Cc:     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 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?


Powered by blists - more mailing lists