linux-kernel - Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP

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: <CAMuHMdVBBnH2REi4RP6N6S5PaCgrwFteHXPRtnr9jPwtUbx_qA@mail.gmail.com>
Date:   Fri, 5 Jan 2018 10:16:53 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linux PM <linux-pm@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Simon Horman <horms@...ge.net.au>,
        Niklas Soderlund <niklas.soderlund+renesas@...natech.se>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        linux-gpio@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

Hi Rafael,

On Sun, Dec 31, 2017 at 12:47 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Sun, Dec 31, 2017 at 10:22 AM, Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
>> On Sun, Dec 31, 2017 at 1:56 AM, Rafael J. Wysocki <rafael@...nel.org> wrote:
>>> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>>>> From: Geert Uytterhoeven <geert+renesas@...der.be>
>>>>
>>>> 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]
>>>> https://lkml.org/lkml/2017/11/9/382
>>>> [2]
>>>> https://marc.info/?l=linux-pm&m=151454744124661&w=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.
>
> OK
>
> 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?

The irq_desc is per pin, while suspend is called per platform device, which
contains one or more irq_chips, each serving one or more pins.
So checking for IRQD_WAKEUP_STATE means looping over all irq_descs
associated to the platform device.

Which made me realize {gpio_rcar,irqc,intc_irqpin}_priv.wakeup_path should
not be a flag, but a counter. Currently it works by luck, as we never have
two independent wake-up sources being routed through the same irqchip.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds