06 Mar, 2015

1 commit

  • With certain restrictions it is possible for a wakeup device to share
    an IRQ with an IRQF_NO_SUSPEND user, and the warnings introduced by
    commit cab303be91dc47942bc25de33dc1140123540800 are spurious. The new
    IRQF_COND_SUSPEND flag allows drivers to tell the core when these
    restrictions are met, allowing spurious warnings to be silenced.

    This patch documents how IRQF_COND_SUSPEND is expected to be used,
    updating some of the text now made invalid by its addition.

    Signed-off-by: Mark Rutland
    Signed-off-by: Rafael J. Wysocki

    Mark Rutland
     

26 Feb, 2015

1 commit

  • The IRQF_NO_SUSPEND flag is intended to be used for interrupts required
    to be enabled during the suspend-resume cycle. This mostly consists of
    IPIs and timer interrupts, potentially including chained irqchip
    interrupts if these are necessary to handle timers or IPIs. If an
    interrupt does not fall into one of the aforementioned categories,
    requesting it with IRQF_NO_SUSPEND is likely incorrect.

    Using IRQF_NO_SUSPEND does not guarantee that the interrupt can wake the
    system from a suspended state. For an interrupt to be able to trigger a
    wakeup, it may be necessary to program various components of the system.
    In these cases it is necessary to use {enable,disabled}_irq_wake.

    Unfortunately, several drivers assume that IRQF_NO_SUSPEND ensures that
    an IRQ can wake up the system, and the documentation can be read
    ambiguously w.r.t. this property.

    This patch updates the documentation regarding IRQF_NO_SUSPEND to make
    this caveat explicit, hopefully making future misuse rarer. Cleanup of
    existing misuse will occur as part of later patch series.

    Signed-off-by: Mark Rutland
    Acked-by: Peter Zijlstra (Intel)
    Signed-off-by: Rafael J. Wysocki

    Mark Rutland
     

08 Nov, 2014

1 commit


01 Sep, 2014

1 commit