Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

["Rafael J. Wysocki" <rafael@xxxxxxxxxx>]

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> From: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
>
> 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?

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html