From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752861AbbLCSfk (ORCPT ); Thu, 3 Dec 2015 13:35:40 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]:48299 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752406AbbLCSfj (ORCPT ); Thu, 3 Dec 2015 13:35:39 -0500 Subject: Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag To: Tony Lindgren , Linus Walleij References: <1448644860-29323-1-git-send-email-sudeep.holla@arm.com> <1448644860-29323-2-git-send-email-sudeep.holla@arm.com> <20151203181337.GV23396@atomide.com> CC: Sudeep Holla , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , From: Grygorii Strashko Message-ID: <56608B72.1040101@ti.com> Date: Thu, 3 Dec 2015 20:35:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151203181337.GV23396@atomide.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/03/2015 08:13 PM, Tony Lindgren wrote: > * Linus Walleij [151201 06:07]: >> On Fri, Nov 27, 2015 at 6:21 PM, Sudeep Holla wrote: >> >>> From: Sudeep Holla >>> >>> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should >>> be left enabled so as to allow them to work as expected during the >>> suspend-resume cycle, but doesn't guarantee that it will wake the system >>> from a suspended state, enable_irq_wake is recommended to be used for >>> the wakeup. >>> >>> This patch removes the use of IRQF_NO_SUSPEND flags replacing it with >>> irq_set_irq_wake instead. >>> >>> Cc: Linus Walleij >>> Cc: linux-gpio@vger.kernel.org >>> Signed-off-by: Sudeep Holla >> >> I need Tony's ACK on this as well. > > At least on omaps, this controller is always powered and we never want to > suspend it as it handles wake-up events for all the IO pins. And that > usecase sounds exactly like what you're describing above. > > I don't quite follow what your suggested alternative for an interrupt > controller is? > > At least we need to have the alternative patched in with this chage before > just removing IRQF_NO_SUSPEND. > > The enable_irq_wake is naturally used for the consumer drivers of this > interrupt controller and actually mostly done automatically now with the > dev_pm_set_dedicated_wake_irq. > I think, this patch should not break our wake-up functionality. It will just change the moment when pcs_irq_handler() will be called: before this change: - suspend_enter() .... - arch_suspend_enable_irqs(); - ^ right here after this change: - suspend_enter() .... dpm_resume_noirq() - resume_device_irqs() ^ here Correct? And as for me this is more safe. -- regards, -grygorii