From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E247FC433E0 for ; Fri, 15 Jan 2021 04:05:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A62AA235F8 for ; Fri, 15 Jan 2021 04:05:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729955AbhAOEFX (ORCPT ); Thu, 14 Jan 2021 23:05:23 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:59341 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729152AbhAOEFX (ORCPT ); Thu, 14 Jan 2021 23:05:23 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 6868F15AD; Thu, 14 Jan 2021 23:04:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 14 Jan 2021 23:04:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=m iv0kQgf9qxy5Btjbf60hP7klLvl7l2WrF4uzxnahAM=; b=kZSMnFmxuSthPoeAc 1VcoCw+oPGvL8reaPBQaCogrsEGzHViOSuT8oEaelv4eYcI891LzgD8xauJeOA7/ zSlNDc++z6AvK0zIwiLPl2Ky9DHHxgGqxtWKHXB2+l2YMcHYQ+ReKjXFedvEDKAv gVaTBWOwCa6pdEhRop4unAyoH+nsliXH8LKVNHHkDm77xX3VbXKXQVxT2LWlbOZV fa9lL4DoCvmxEWoaY/wqF3rmE0QtWqvsB9kt4NW7MQdJvgq7Tom9lJQvlCHxQiFc GW73PgD+i9OxN0I5177SgPZpV3iNzGJcTehyBmJ5gGkkDMNgL3vdzM3NzKskZA9X evelQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=miv0kQgf9qxy5Btjbf60hP7klLvl7l2WrF4uzxnah AM=; b=bweC5aEdpdGd2rnEfWWR3+5PuinhEfnt3fULSY6h+4+xT5Rre13jHyQZJ FSFST3yfvNOUXfNKErDHXh5El7X2L3J5aTymDSe/+8iNnhZKHg7LHTN+MZ0U0bYm yDgNxui33102hnntDUcaucgP/P2HY9AyKsXT4sQsy+2kv+iVoxHSwDiokyGfo4KJ 3lbwLSQQFj8TC3eb8IXdt+yJ3UX+oollxP3J+mlR7n6y10n6tq9YYXoDuu7Qugaq MoySde2Ed9VgqMzvHznPim7uNPJg7PjCdYnbJnPP6t3uKwlvf0SbJLe5hIgIjMpq HUESdb2tZFbypb3hP1/SFI456FL7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtddugdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefurghmuhgv lhcujfholhhlrghnugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtf frrghtthgvrhhnpefgveffteelheffjeeukedvkedviedtheevgeefkeehueeiieeuteeu gfettdeggeenucfkphepjedtrddufeehrddugeekrdduhedunecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshgrmhhuvghlsehshhholhhlrghn ugdrohhrgh X-ME-Proxy: Received: from [70.135.148.151] (70-135-148-151.lightspeed.stlsmo.sbcglobal.net [70.135.148.151]) by mail.messagingengine.com (Postfix) with ESMTPA id 756711080057; Thu, 14 Jan 2021 23:04:15 -0500 (EST) Subject: Re: [PATCH v4 04/10] irqchip/sun6i-r: Add wakeup support To: Marc Zyngier Cc: Thomas Gleixner , Rob Herring , Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Ondrej Jirman , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20210112055950.21209-1-samuel@sholland.org> <20210112055950.21209-5-samuel@sholland.org> <87sg73jirb.wl-maz@kernel.org> From: Samuel Holland Message-ID: Date: Thu, 14 Jan 2021 22:04:15 -0600 User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <87sg73jirb.wl-maz@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/14/21 3:44 PM, Marc Zyngier wrote: > On Tue, 12 Jan 2021 05:59:44 +0000, > Samuel Holland wrote: >> >> Maintain bitmaps of wake-enabled IRQs and mux inputs, and program them >> to the hardware during the syscore phase of suspend and shutdown. Then >> restore the original set of enabled IRQs (only the NMI) during resume. >> >> This serves two purposes. First, it lets power management firmware >> running on the ARISC coprocessor know which wakeup sources Linux wants >> to have enabled. That way, it can avoid turning them off when it shuts >> down the remainder of the clock tree. Second, it preconfigures the >> coprocessor's interrupt controller, so the firmware's wakeup logic >> is as simple as waiting for an interrupt to arrive. >> >> The suspend/resume logic is not conditional on PM_SLEEP because it is >> identical to the init/shutdown logic. Wake IRQs may be enabled during >> shutdown to allow powering the board back on. As an example, see >> commit a5c5e50cce9d ("Input: gpio-keys - add shutdown callback"). >> >> Signed-off-by: Samuel Holland >> --- >> drivers/irqchip/irq-sun6i-r.c | 107 ++++++++++++++++++++++++++++++++-- >> 1 file changed, 101 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/irqchip/irq-sun6i-r.c b/drivers/irqchip/irq-sun6i-r.c >> index d04d067423f4..a1b58c98d6ca 100644 >> --- a/drivers/irqchip/irq-sun6i-r.c >> +++ b/drivers/irqchip/irq-sun6i-r.c >> @@ -39,6 +39,7 @@ >> * set of 128 mux bits. This requires a second set of top-level registers. >> */ >> >> +#include >> #include >> #include >> #include >> @@ -46,6 +47,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> >> @@ -67,8 +69,17 @@ >> #define SUN6I_NR_DIRECT_IRQS 16 >> #define SUN6I_NR_MUX_BITS 128 >> >> +struct sun6i_r_intc_variant { >> + u32 first_mux_irq; >> + u32 nr_mux_irqs; >> + u32 mux_valid[BITS_TO_U32(SUN6I_NR_MUX_BITS)]; >> +}; >> + >> static void __iomem *base; >> static irq_hw_number_t nmi_hwirq; >> +static DECLARE_BITMAP(wake_irq_enabled, SUN6I_NR_TOP_LEVEL_IRQS); >> +static DECLARE_BITMAP(wake_mux_enabled, SUN6I_NR_MUX_BITS); >> +static DECLARE_BITMAP(wake_mux_valid, SUN6I_NR_MUX_BITS); >> >> static void sun6i_r_intc_ack_nmi(void) >> { >> @@ -145,6 +156,21 @@ static int sun6i_r_intc_nmi_set_irqchip_state(struct irq_data *data, >> return irq_chip_set_parent_state(data, which, state); >> } >> >> +static int sun6i_r_intc_irq_set_wake(struct irq_data *data, unsigned int on) >> +{ >> + unsigned long offset_from_nmi = data->hwirq - nmi_hwirq; >> + >> + if (offset_from_nmi < SUN6I_NR_DIRECT_IRQS) >> + assign_bit(offset_from_nmi, wake_irq_enabled, on); >> + else if (test_bit(data->hwirq, wake_mux_valid)) >> + assign_bit(data->hwirq, wake_mux_enabled, on); >> + else >> + /* Not wakeup capable. */ >> + return -EPERM; >> + >> + return 0; >> +} >> + >> static struct irq_chip sun6i_r_intc_nmi_chip = { >> .name = "sun6i-r-intc", >> .irq_ack = sun6i_r_intc_nmi_ack, >> @@ -154,8 +180,19 @@ static struct irq_chip sun6i_r_intc_nmi_chip = { >> .irq_set_affinity = irq_chip_set_affinity_parent, >> .irq_set_type = sun6i_r_intc_nmi_set_type, >> .irq_set_irqchip_state = sun6i_r_intc_nmi_set_irqchip_state, >> - .flags = IRQCHIP_SET_TYPE_MASKED | >> - IRQCHIP_SKIP_SET_WAKE, >> + .irq_set_wake = sun6i_r_intc_irq_set_wake, >> + .flags = IRQCHIP_SET_TYPE_MASKED, >> +}; >> + >> +static struct irq_chip sun6i_r_intc_wakeup_chip = { >> + .name = "sun6i-r-intc", >> + .irq_mask = irq_chip_mask_parent, >> + .irq_unmask = irq_chip_unmask_parent, >> + .irq_eoi = irq_chip_eoi_parent, >> + .irq_set_affinity = irq_chip_set_affinity_parent, >> + .irq_set_type = irq_chip_set_type_parent, >> + .irq_set_wake = sun6i_r_intc_irq_set_wake, >> + .flags = IRQCHIP_SET_TYPE_MASKED, > > Worth implementing irq_get/set_irqchip_state() using the _parent > helper, I guess. This is the same situation as the previous patch. Assuming it is safe to rely on the behavior of the top-level functions, adding the callbacks here would be redundant. Cheers, Samuel > Thanks, > > M. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D01BBC433E0 for ; Fri, 15 Jan 2021 04:05:36 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5E00A235F8 for ; Fri, 15 Jan 2021 04:05:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E00A235F8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sholland.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9QQrk6s9qKtyYvawaK64xU9csdeIpbNRhFgYh0HO3yM=; b=mLVEyzpzJ4hKvmIeh7ZeVbzol nOG4UGUtSoF2CZ/6KwuPcEYOByxVOQgTCqtAQkEpPDLLZZ8x2DF+UfHUuhPSQG7X9dAWKYESSYKaS 4xCh6RxwCiofRZs/OQw0TkP675LRw90mJt8UJlLwW6FBMovOuQxuIBsOhkH6tQs7snFAO+GdpPre4 ZOMjXF4066xbLupnpOG2pChOPkssJCOP0oJSBz6hABtUBy8QgDR34qCFlb1/KyDJG0rRfaTtWDxDi r1fuQwOH4/9g/t4XVpCuuw5IJgtrrizn4UsYL03wm0k0DHxLldXWSBQqUB3aYcwqH2EBHa/tajajo EAF+Gj6tg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0GLU-0006gZ-IS; Fri, 15 Jan 2021 04:04:20 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0GLS-0006g8-2Q for linux-arm-kernel@lists.infradead.org; Fri, 15 Jan 2021 04:04:18 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 6868F15AD; Thu, 14 Jan 2021 23:04:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 14 Jan 2021 23:04:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=m iv0kQgf9qxy5Btjbf60hP7klLvl7l2WrF4uzxnahAM=; b=kZSMnFmxuSthPoeAc 1VcoCw+oPGvL8reaPBQaCogrsEGzHViOSuT8oEaelv4eYcI891LzgD8xauJeOA7/ zSlNDc++z6AvK0zIwiLPl2Ky9DHHxgGqxtWKHXB2+l2YMcHYQ+ReKjXFedvEDKAv gVaTBWOwCa6pdEhRop4unAyoH+nsliXH8LKVNHHkDm77xX3VbXKXQVxT2LWlbOZV fa9lL4DoCvmxEWoaY/wqF3rmE0QtWqvsB9kt4NW7MQdJvgq7Tom9lJQvlCHxQiFc GW73PgD+i9OxN0I5177SgPZpV3iNzGJcTehyBmJ5gGkkDMNgL3vdzM3NzKskZA9X evelQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=miv0kQgf9qxy5Btjbf60hP7klLvl7l2WrF4uzxnah AM=; b=bweC5aEdpdGd2rnEfWWR3+5PuinhEfnt3fULSY6h+4+xT5Rre13jHyQZJ FSFST3yfvNOUXfNKErDHXh5El7X2L3J5aTymDSe/+8iNnhZKHg7LHTN+MZ0U0bYm yDgNxui33102hnntDUcaucgP/P2HY9AyKsXT4sQsy+2kv+iVoxHSwDiokyGfo4KJ 3lbwLSQQFj8TC3eb8IXdt+yJ3UX+oollxP3J+mlR7n6y10n6tq9YYXoDuu7Qugaq MoySde2Ed9VgqMzvHznPim7uNPJg7PjCdYnbJnPP6t3uKwlvf0SbJLe5hIgIjMpq HUESdb2tZFbypb3hP1/SFI456FL7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtddugdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefurghmuhgv lhcujfholhhlrghnugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtf frrghtthgvrhhnpefgveffteelheffjeeukedvkedviedtheevgeefkeehueeiieeuteeu gfettdeggeenucfkphepjedtrddufeehrddugeekrdduhedunecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshgrmhhuvghlsehshhholhhlrghn ugdrohhrgh X-ME-Proxy: Received: from [70.135.148.151] (70-135-148-151.lightspeed.stlsmo.sbcglobal.net [70.135.148.151]) by mail.messagingengine.com (Postfix) with ESMTPA id 756711080057; Thu, 14 Jan 2021 23:04:15 -0500 (EST) Subject: Re: [PATCH v4 04/10] irqchip/sun6i-r: Add wakeup support To: Marc Zyngier References: <20210112055950.21209-1-samuel@sholland.org> <20210112055950.21209-5-samuel@sholland.org> <87sg73jirb.wl-maz@kernel.org> From: Samuel Holland Message-ID: Date: Thu, 14 Jan 2021 22:04:15 -0600 User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <87sg73jirb.wl-maz@kernel.org> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210114_230418_191220_FB27CC40 X-CRM114-Status: GOOD ( 23.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ondrej Jirman , devicetree@vger.kernel.org, Jernej Skrabec , linux-kernel@vger.kernel.org, Maxime Ripard , Chen-Yu Tsai , Rob Herring , Thomas Gleixner , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/14/21 3:44 PM, Marc Zyngier wrote: > On Tue, 12 Jan 2021 05:59:44 +0000, > Samuel Holland wrote: >> >> Maintain bitmaps of wake-enabled IRQs and mux inputs, and program them >> to the hardware during the syscore phase of suspend and shutdown. Then >> restore the original set of enabled IRQs (only the NMI) during resume. >> >> This serves two purposes. First, it lets power management firmware >> running on the ARISC coprocessor know which wakeup sources Linux wants >> to have enabled. That way, it can avoid turning them off when it shuts >> down the remainder of the clock tree. Second, it preconfigures the >> coprocessor's interrupt controller, so the firmware's wakeup logic >> is as simple as waiting for an interrupt to arrive. >> >> The suspend/resume logic is not conditional on PM_SLEEP because it is >> identical to the init/shutdown logic. Wake IRQs may be enabled during >> shutdown to allow powering the board back on. As an example, see >> commit a5c5e50cce9d ("Input: gpio-keys - add shutdown callback"). >> >> Signed-off-by: Samuel Holland >> --- >> drivers/irqchip/irq-sun6i-r.c | 107 ++++++++++++++++++++++++++++++++-- >> 1 file changed, 101 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/irqchip/irq-sun6i-r.c b/drivers/irqchip/irq-sun6i-r.c >> index d04d067423f4..a1b58c98d6ca 100644 >> --- a/drivers/irqchip/irq-sun6i-r.c >> +++ b/drivers/irqchip/irq-sun6i-r.c >> @@ -39,6 +39,7 @@ >> * set of 128 mux bits. This requires a second set of top-level registers. >> */ >> >> +#include >> #include >> #include >> #include >> @@ -46,6 +47,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> >> @@ -67,8 +69,17 @@ >> #define SUN6I_NR_DIRECT_IRQS 16 >> #define SUN6I_NR_MUX_BITS 128 >> >> +struct sun6i_r_intc_variant { >> + u32 first_mux_irq; >> + u32 nr_mux_irqs; >> + u32 mux_valid[BITS_TO_U32(SUN6I_NR_MUX_BITS)]; >> +}; >> + >> static void __iomem *base; >> static irq_hw_number_t nmi_hwirq; >> +static DECLARE_BITMAP(wake_irq_enabled, SUN6I_NR_TOP_LEVEL_IRQS); >> +static DECLARE_BITMAP(wake_mux_enabled, SUN6I_NR_MUX_BITS); >> +static DECLARE_BITMAP(wake_mux_valid, SUN6I_NR_MUX_BITS); >> >> static void sun6i_r_intc_ack_nmi(void) >> { >> @@ -145,6 +156,21 @@ static int sun6i_r_intc_nmi_set_irqchip_state(struct irq_data *data, >> return irq_chip_set_parent_state(data, which, state); >> } >> >> +static int sun6i_r_intc_irq_set_wake(struct irq_data *data, unsigned int on) >> +{ >> + unsigned long offset_from_nmi = data->hwirq - nmi_hwirq; >> + >> + if (offset_from_nmi < SUN6I_NR_DIRECT_IRQS) >> + assign_bit(offset_from_nmi, wake_irq_enabled, on); >> + else if (test_bit(data->hwirq, wake_mux_valid)) >> + assign_bit(data->hwirq, wake_mux_enabled, on); >> + else >> + /* Not wakeup capable. */ >> + return -EPERM; >> + >> + return 0; >> +} >> + >> static struct irq_chip sun6i_r_intc_nmi_chip = { >> .name = "sun6i-r-intc", >> .irq_ack = sun6i_r_intc_nmi_ack, >> @@ -154,8 +180,19 @@ static struct irq_chip sun6i_r_intc_nmi_chip = { >> .irq_set_affinity = irq_chip_set_affinity_parent, >> .irq_set_type = sun6i_r_intc_nmi_set_type, >> .irq_set_irqchip_state = sun6i_r_intc_nmi_set_irqchip_state, >> - .flags = IRQCHIP_SET_TYPE_MASKED | >> - IRQCHIP_SKIP_SET_WAKE, >> + .irq_set_wake = sun6i_r_intc_irq_set_wake, >> + .flags = IRQCHIP_SET_TYPE_MASKED, >> +}; >> + >> +static struct irq_chip sun6i_r_intc_wakeup_chip = { >> + .name = "sun6i-r-intc", >> + .irq_mask = irq_chip_mask_parent, >> + .irq_unmask = irq_chip_unmask_parent, >> + .irq_eoi = irq_chip_eoi_parent, >> + .irq_set_affinity = irq_chip_set_affinity_parent, >> + .irq_set_type = irq_chip_set_type_parent, >> + .irq_set_wake = sun6i_r_intc_irq_set_wake, >> + .flags = IRQCHIP_SET_TYPE_MASKED, > > Worth implementing irq_get/set_irqchip_state() using the _parent > helper, I guess. This is the same situation as the previous patch. Assuming it is safe to rely on the behavior of the top-level functions, adding the callbacks here would be redundant. Cheers, Samuel > Thanks, > > M. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel