Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp422758ybv; Wed, 5 Feb 2020 07:55:07 -0800 (PST) X-Google-Smtp-Source: APXvYqyYdXdwvefNdCHUQi5n9szhy2XixhPf6q3kEa6c3eUfbCHR+QoEC0XVuFuUhonTfGAWM/rQ X-Received: by 2002:aca:1c0d:: with SMTP id c13mr3238742oic.44.1580918107232; Wed, 05 Feb 2020 07:55:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580918107; cv=none; d=google.com; s=arc-20160816; b=eeyRwDe2fRjtkz3KHzCnSI+FDOpgtahVsom8EJgGcVNgcHPGezrOdcaSe7uViYFr80 GlFDHVV00a4Gsl74nQbeNDfuu72XzzSr8JxitrOV+wnx3uRcYCGCFl3uXrjnVKV4WiK+ F3uPfUr6beQpiRkNTndob5+sGL6L3CL2u1XqG413fFI3UasS3ABehsJATsfOgjo5qNnc kaNPOErXH4jgJJT4FHJOa+b6fhO3vrH4HC7EvKq2mFqF4lh0s/nFtB+VgWh2APgHraDy WOvGJ002x4pTyZJAmcBTgOnQSr+8KlcbAvN5J2vaNTavYBc/Lbt2WZzIlk+ozuNXnpxf LIhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=xpc+Kj1kwuhA3kQ0MdaGaqD66LXGFFFPxtKiiEmLl/0=; b=bLT8Y7KZhFyzmipGXpHPUNjp9fsEioKQOi+anPbzqmazZjWFYj1wVytu3AJuw43vi0 OnTLxdCBx74KZZkq/KCKweslnxsZJi+SGo0iLSQXauLxpmVuq5NJLCbyuuhw0erTpCNd tEHIr+sClMUPnFrhjKm3py7k5w6HYJrBuEO8ilfxoymhHjRSoHtBtRAtwLh1xvRYy90Q o2r15hdmpMYxD9fZ0tN8lIaw7x8t69mJvaUakvTb4QRRK4kWpm5Bph1tusU1Fvrp6hL6 rowBWHjLyZbPTtuR8+3WxatCJZi3l7EQT9Bip9IlZtObuxDmDap3K7uGcfdC0mAe0QVn 2x1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g25si14066680otp.20.2020.02.05.07.54.54; Wed, 05 Feb 2020 07:55:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727170AbgBEPxG (ORCPT + 99 others); Wed, 5 Feb 2020 10:53:06 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:35897 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726413AbgBEPxG (ORCPT ); Wed, 5 Feb 2020 10:53:06 -0500 Received: from [212.187.182.165] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1izMz8-0004hJ-2L; Wed, 05 Feb 2020 16:53:02 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 8BAD0100C31; Wed, 5 Feb 2020 15:52:56 +0000 (GMT) From: Thomas Gleixner To: Lina Iyer Cc: Stephen Boyd , linux-kernel@vger.kernel.org, Marc Zyngier , Douglas Anderson , Maulik Shah Subject: Re: [PATCH] genirq: Clarify that irq wake state is orthogonal to enable/disable In-Reply-To: <20200205153410.GA3898@codeaurora.org> References: <20200205060953.49167-1-swboyd@chromium.org> <87zhdxrzhh.fsf@nanos.tec.linutronix.de> <20200205153410.GA3898@codeaurora.org> Date: Wed, 05 Feb 2020 15:52:56 +0000 Message-ID: <87tv45rpyf.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Lina Iyer writes: > On Wed, Feb 05 2020 at 05:27 -0700, Thomas Gleixner wrote: >>> @@ -731,6 +731,11 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on) >>> * >>> * Wakeup mode lets this IRQ wake the system from sleep >>> * states like "suspend to RAM". >>> + * >>> + * Note: irq enable/disable state is completely orthogonal >>> + * to the enable/disable state of irq wake. An irq can be >>> + * disabled with disable_irq() and still wake the system as >>> + * long as the irq has wake enabled. >> >>It clearly should say that this is really depending on the hardware >>implementation of the particual interrupt chip whether disabled + wake >>mode is supported. >> > Could an irqchip flag be used to warn users that we may not wakeup from > suspend/resume if the interrupt if the hardware does not support wakeup > when disabled ? There are also magic ways of wakeup for irqchips which do not have wake setup functions and still wake the system up when the interrupt line is disabled by the kernel on suspend. :) Thanks, tglx