From patchwork Tue Jun 27 07:32:50 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Lindgren X-Patchwork-Id: 9810973 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5F83660329 for ; Tue, 27 Jun 2017 07:32:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4E8991FF27 for ; Tue, 27 Jun 2017 07:32:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 42DEC2818A; Tue, 27 Jun 2017 07:32:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A24141FF27 for ; Tue, 27 Jun 2017 07:32:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751534AbdF0Hc4 (ORCPT ); Tue, 27 Jun 2017 03:32:56 -0400 Received: from muru.com ([72.249.23.125]:59170 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751492AbdF0Hcz (ORCPT ); Tue, 27 Jun 2017 03:32:55 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 742A3812D; Tue, 27 Jun 2017 07:33:05 +0000 (UTC) Date: Tue, 27 Jun 2017 00:32:50 -0700 From: Tony Lindgren To: Brian Norris Cc: Thomas Gleixner , Heiko Stuebner , Linus Walleij , linux-rockchip@lists.infradead.org, Julia Cartwright , LKML , linux-gpio@vger.kernel.org, John Keeping , linux-pm@vger.kernel.org, Doug Anderson , "Paul E. McKenney" , Peter Zijlstra , "David.Wu" , =?utf-8?B?J+m7hOa2myc=?= Subject: Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip" Message-ID: <20170627073249.GY3730@atomide.com> References: <20170517225634.GA11404@google.com> <20170527021900.GA119873@google.com> <20170623205911.GA143883@google.com> <20170627000622.GA63039@google.com> <20170627062409.GX3730@atomide.com> <20170627070731.GA23083@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170627070731.GA23083@google.com> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP * Brian Norris [170627 00:07]: > On Mon, Jun 26, 2017 at 11:24:09PM -0700, Tony Lindgren wrote: > > Hmm so how come drivers/bluetooth/btusb.c can't use the generic > > dev_pm_set_dedicated_wake_irq()? Can you please take a look? > > I took a look previously, and last time I did, there were too many bugs > for it to be useful. You may have fixed the ones I reported w.r.t. > assumptions about runtime PM. Yes several issues got fixed over past few years. If you find issues please let me know, otherwise I can't help. > I also recall there being some difficulty with supporting > level-triggered interrupts that way. (This signal has no device-level > mask, and it triggers for all sorts of BT activity. There may not be a > relevant "edge".) Well typically the wakeirq needs to be disabled during runtime like we do for the generic wakeirqs. It might be connected to the RX line for example so it's just noise during runtime. If you actually need it during runtime then it's a separate story but I doubt that's the case here. Talking of GPIO interrupt triggering, I wonder if something like below might help? It seems we're missing the setting of triggering, see below. > > If there are issues remaining let's rather fix them so we can get rid > > of the custom tinkering of wake-up events in the drivers. > > That's nice, but that doesn't answer my questions. Perhaps that's a side > project. The point is that we're clearly violating the documented APIs. Certainly all these issues need to be fixed if we intent to use it. Funny how I have not run into these with my test cases. Do you have a GPIO irqchip on I2C for handling the wake-up interrupts? Regards, Tony 8< ------- diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c --- a/drivers/base/power/wakeirq.c +++ b/drivers/base/power/wakeirq.c @@ -198,7 +198,8 @@ int dev_pm_set_dedicated_wake_irq(struct device *dev, int irq) * so we use a threaded irq. */ err = request_threaded_irq(irq, NULL, handle_threaded_wake_irq, - IRQF_ONESHOT, dev_name(dev), wirq); + irq_get_trigger_type(irq) | IRQF_ONESHOT, + dev_name(dev), wirq); if (err) goto err_free;