From patchwork Wed Mar 4 20:00:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 5939981 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 78B589F36A for ; Wed, 4 Mar 2015 20:01:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F02F520295 for ; Wed, 4 Mar 2015 20:01:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0716F20320 for ; Wed, 4 Mar 2015 20:01:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755152AbbCDUBM (ORCPT ); Wed, 4 Mar 2015 15:01:12 -0500 Received: from foss.arm.com ([217.140.101.70]:54714 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755135AbbCDUBK (ORCPT ); Wed, 4 Mar 2015 15:01:10 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E42E62A; Wed, 4 Mar 2015 12:01:29 -0800 (PST) Received: from collaborate-mta1.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTP id B1A083F24F; Wed, 4 Mar 2015 12:01:09 -0800 (PST) Received: from leverpostej (leverpostej.cambridge.arm.com [10.1.205.151]) by collaborate-mta1.arm.com (Postfix) with ESMTPS id 1D27613F8B9; Wed, 4 Mar 2015 14:01:07 -0600 (CST) Date: Wed, 4 Mar 2015 20:00:40 +0000 From: Mark Rutland To: "Rafael J. Wysocki" Cc: Boris Brezillon , Peter Zijlstra , Thomas Gleixner , Jason Cooper , "linux-kernel@vger.kernel.org" , Nicolas Ferre , Jean-Christophe Plagniol-Villard , Alexandre Belloni , "linux-arm-kernel@lists.infradead.org" , Linux PM list Subject: [PATCH] genirq: describe IRQF_COND_SUSPEND Message-ID: <20150304200040.GA12126@leverpostej> References: <1424771762-16343-1-git-send-email-boris.brezillon@free-electrons.com> <8151717.nkhnGBri9h@vostro.rjw.lan> <20150226191724.0ae4ca4e@bbrezillon> <6864616.1aRDSmSsvx@vostro.rjw.lan> <20150304194246.GF22156@leverpostej> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150304194246.GF22156@leverpostej> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP With certain restrictions it is possible for a wakeup device to share and 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 Cc: Boris Brezillon Cc: Peter Zijlstra Cc: Rafael J. Wysocki --- Documentation/power/suspend-and-interrupts.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) As promised previously, take IRQF_COND_SUSPEND into account in the documentation. Rafael, does this look OK to you? Thanks, Mark. diff --git a/Documentation/power/suspend-and-interrupts.txt b/Documentation/power/suspend-and-interrupts.txt index 50493c9..8afb29a 100644 --- a/Documentation/power/suspend-and-interrupts.txt +++ b/Documentation/power/suspend-and-interrupts.txt @@ -112,8 +112,9 @@ any special interrupt handling logic for it to work. IRQF_NO_SUSPEND and enable_irq_wake() ------------------------------------- -There are no valid reasons to use both enable_irq_wake() and the IRQF_NO_SUSPEND -flag on the same IRQ. +There are very few valid reasons to use both enable_irq_wake() and the +IRQF_NO_SUSPEND flag on the same IRQ, and it is never valid to use both for the +same device. First of all, if the IRQ is not shared, the rules for handling IRQF_NO_SUSPEND interrupts (interrupt handlers are invoked after suspend_device_irqs()) are @@ -122,4 +123,13 @@ handlers are not invoked after suspend_device_irqs()). Second, both enable_irq_wake() and IRQF_NO_SUSPEND apply to entire IRQs and not to individual interrupt handlers, so sharing an IRQ between a system wakeup -interrupt source and an IRQF_NO_SUSPEND interrupt source does not make sense. +interrupt source and an IRQF_NO_SUSPEND interrupt source does not generally +make sense. + +In rare cases an IRQ can be shared between a wakeup device driver and an +IRQF_NO_SUSPEND user. In order for this to be safe, the wakeup device driver +must be able to discern spurious IRQs from genuine wakeup events (signalling +the latter to the core with pm_system_wakeup()), must use enable_irq_wake() to +ensure that the IRQ will function as a wakeup source, and must request the IRQ +with IRQF_COND_SUSPEND to tell the core that it meets these requirements. If +these requirements are not met, it is not valid to use IRQF_COND_SUSPEND.