From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: rtc-linux@googlegroups.com Received: from foss.arm.com (foss.arm.com. [217.140.101.70]) by gmr-mx.google.com with ESMTP id m28si633268pfa.0.2016.06.03.02.04.42 for ; Fri, 03 Jun 2016 02:04:42 -0700 (PDT) Subject: [rtc-linux] Re: [PATCH] rtc: ab8500: move device_init_wakeup() call To: Linus Walleij References: <1464875584-31505-1-git-send-email-linus.walleij@linaro.org> Cc: Alessandro Zummo , Alexandre Belloni , Sudeep Holla , rtc-linux@googlegroups.com, stable@vger.kernel.org, Ulf Hansson From: Sudeep Holla Message-ID: <57514826.8030801@arm.com> Date: Fri, 3 Jun 2016 10:04:38 +0100 MIME-Version: 1.0 In-Reply-To: <1464875584-31505-1-git-send-email-linus.walleij@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , On 02/06/16 14:53, Linus Walleij wrote: > commit 93a6f9168f2f ("rtc: ab8500: remove misuse of IRQF_NO_SUSPEND flag") > introduced the dev_pm_set_wake_irq() call to register a wake > IRQ for the AB8500 driver. > > However this causes a regression since device_init_wakeup() must be > called *after* dev_pm_set_wake_irq() not *before* it. Before this > patch we get an error message like this during system resume from > sleep: > I am unable to understand this. Because it's the exact same sequence in rtc-pl031.c which works fine for me on ARM64 Juno platform. So I am struggle to understand the linkage of the backtrace to this calling sequence as I can't see any dependency. Let me know if you have already figured out where exactly does it go wrong. Prior to commit 93a6f9168f2f, set_irq_wake was never tested and hence one possible reason I can think of is set_irq_wake_real may be failing on suspend but the error value is ignored. -- Regards, Sudeep -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com ([217.140.101.70]:50668 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932097AbcFCJEm (ORCPT ); Fri, 3 Jun 2016 05:04:42 -0400 Subject: Re: [PATCH] rtc: ab8500: move device_init_wakeup() call To: Linus Walleij References: <1464875584-31505-1-git-send-email-linus.walleij@linaro.org> Cc: Alessandro Zummo , Alexandre Belloni , Sudeep Holla , rtc-linux@googlegroups.com, stable@vger.kernel.org, Ulf Hansson From: Sudeep Holla Message-ID: <57514826.8030801@arm.com> Date: Fri, 3 Jun 2016 10:04:38 +0100 MIME-Version: 1.0 In-Reply-To: <1464875584-31505-1-git-send-email-linus.walleij@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 02/06/16 14:53, Linus Walleij wrote: > commit 93a6f9168f2f ("rtc: ab8500: remove misuse of IRQF_NO_SUSPEND flag") > introduced the dev_pm_set_wake_irq() call to register a wake > IRQ for the AB8500 driver. > > However this causes a regression since device_init_wakeup() must be > called *after* dev_pm_set_wake_irq() not *before* it. Before this > patch we get an error message like this during system resume from > sleep: > I am unable to understand this. Because it's the exact same sequence in rtc-pl031.c which works fine for me on ARM64 Juno platform. So I am struggle to understand the linkage of the backtrace to this calling sequence as I can't see any dependency. Let me know if you have already figured out where exactly does it go wrong. Prior to commit 93a6f9168f2f, set_irq_wake was never tested and hence one possible reason I can think of is set_irq_wake_real may be failing on suspend but the error value is ignored. -- Regards, Sudeep