From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH] genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() Date: Fri, 22 Mar 2019 16:50:20 -0700 Message-ID: <155329862018.20095.14024385652448015564@swboyd.mtv.corp.google.com> References: <20190315200759.139479-1-swboyd@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, Lina Iyer , Marc Zyngier List-Id: linux-gpio@vger.kernel.org Quoting Thomas Gleixner (2019-03-21 02:26:26) > On Fri, 15 Mar 2019, Stephen Boyd wrote: >=20 > > This function returns an error if a child interrupt controller calls > > irq_chip_set_wake_parent() but that parent interrupt controller has the > > IRQCHIP_SKIP_SET_WAKE flag. Let's return 0 for success instead because > > there isn't anything to do. > >=20 > > There's also the possibility that a parent indicates that we should skip > > it, but the grandparent has an .irq_set_wake callback. Let's iterate > > through the parent chain as long as the IRQCHIP_SKIP_SET_WAKE flag isn't > > set so we can find the first parent that needs to handle the wake > > configuration. This fixes a problem on my Qualcomm sdm845 device where > > I'm trying to enable wake on an irq from the gpio controller that's a > > child of the qcom pdc interrupt controller. The qcom pdc interrupt > > controller has the IRQCHIP_SKIP_SET_WAKE flag set, and so does the > > grandparent (ARM GIC), causing this function to return a failure because > > the parent controller doesn't have the .irq_set_wake callback set. >=20 > It took me some time to distangle that changelog.... and I don't think th= at > this is the right thing to do. Yes, your diagram would be a useful addition to the commit text. >=20 > set_irq_wake_real() returns 0 when the topmost chip has SKIP_SET_WAKE set. Just to confirm, the topmost chip would be chip B or chip C below? >=20 > So let's assume we have the following chains: >=20 > chip A -> chip B=20 >=20 > chip A -> chip B -> chip C >=20 > chip A has SKIP_SET_WAKE not set > chip B has SKIP_SET_WAKE set > chip C has SKIP_SET_WAKE not set and invokes irq_chip_set_wake_parent() >=20 > Now assume we have interrupt X connected to chip B and interrupt Y > connected to chip C. >=20 > If irq_set_wake() is called for interrupt X, then the function returns > without trying to invoke the set_wake() callback of chip A. It's not clear to me that having SKIP_SET_WAKE set means "completely ignore set wake for irqs from this domain" vs. "skip setting wake here because the .irq_set_wake() is intentionally omitted for this chip". Reading Santosh's reasoning in commit 60f96b41f71d ("genirq: Add IRQCHIP_SKIP_SET_WAKE flag") just further confuses me because it sounds like the latter. >=20 > If irq_set_wake() is called for interrupt Y, irq_chip_set_wake_parent() is > invoked from chip C which then skips chip B, but tries to invoke the > callback on chip A. >=20 > That's inconsistent and changes the existing behaviour. So IMO, the right > thing to do is to return 0 from irq_chip_set_wake_parent() when the parent > has SKIP_SET_WAKE set and not to try to follow the whole chain. That shou= ld > fix your problem nicely w/o changing behaviour. Ok. I understand that with hierarchical chips you want it to be explicit in the code that a parent chip needs to be called or not. This works for me, and it's actually how I had originally solved this problem. Will you merge your patch or do you want me to resend it with some updated commit text? 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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 7DDA2C4360F for ; Fri, 22 Mar 2019 23:50:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 3C97A21900 for ; Fri, 22 Mar 2019 23:50:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cQ6TAjnX"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="BnZRpwmI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C97A21900 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Date:Message-ID:To:Subject:From: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UZ6kBgawH8lQukMxP/Kz+yYWpR9WIye3PCayveMN0UA=; b=cQ6TAjnXzQzWXq rl2yVeYs40/yQdkYluX2p79mlqTNGEvgpAkrCTlKSf6b5j1ACHFiaAy8Ep01fJFAzNKFVeT6Nj92L F2GCY+n3EXmQdQBXJWEGDOTV4v0bgCvIKudneHvflMUfAOzaQMBpE27gGOpl7CY8nY+6jv0uyK/7N zuTmyXIoS/rbPAJBltXB4r7qTM5cHh9aFaHqZCEjZsGdmxF7F/Kny+babpiHHA1LcaDSNupYT2emv vpAwxaovGemeZd+UhXCPcLl9naelcIWgRm+n41y8nlZniU8MwCR/0KeLeE5KsOL56nrqNfeJqXjeG Y3zPHy3cM6N69ZGPLwFA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h7Tvf-0006Ma-AN; Fri, 22 Mar 2019 23:50:27 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h7Tvb-0006Lw-C9 for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2019 23:50:26 +0000 Received: by mail-pg1-x541.google.com with SMTP id g8so2546495pgf.2 for ; Fri, 22 Mar 2019 16:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:in-reply-to:references:from :subject:cc:to:message-id:user-agent:date; bh=IEOHDcRDNKEttMJKwIZbSUvgHF+/177DDBtgxfrk4Ug=; b=BnZRpwmIGiuonDcgGQtpDZ/91xXwGJAyZOgKcsoMNsgR5LgPheQV42BKLmdqJFmIac UlDEdS01yDRnpNb34opCbw/QpN8KQzluDcUBuQMO7EG2JuTsQcGNFsn4Sq3POGeMyFOu 3+rmBWhyOUCGXdG9a5ufkVgBXcXbF/+xfqEdE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :in-reply-to:references:from:subject:cc:to:message-id:user-agent :date; bh=IEOHDcRDNKEttMJKwIZbSUvgHF+/177DDBtgxfrk4Ug=; b=bqlyxx/Yz4bvE2smE72t7Pc+SPhKgsB100rRLF6fEDRTSxG5Twd/nABDDPXL1ANWsQ 0zOLgqSYJByE5FmFSSGRb1MaF40ImLqzR4IFHMRloAgD8EiC/tY6yU1XzwmLThemxc2C aPUkjYFYKT1tPjCXuFrYO3nLAfpDFE84D/VUuwP+Iwrgw8hWFt1YUJR/+g5rrZwnsctX AhzNfA6xoe6SCqP/QJTwdyfMseT0amzg1fSoGJX/jwiChyaRkY+J/a2jnkHo8v5pkgVF 3LwomjAeu0gxhjuiMHzZvixwXzv4pjVcyLdfYGLOUa93Ax62KYFY/B8UCrIkydkpZfSc TKFw== X-Gm-Message-State: APjAAAX0yb8qg8Sw4N0VU+nUe40aqhwU/hEUAnA0qq8LsB0ITe28vQpz 1BRbuQ1Q+xZDHrplCYBm+GDW5Q== X-Google-Smtp-Source: APXvYqzj+MCmadL4UBD9qDdLShFi9sFsNb7PDKT/0ft/KQPoz4/3C2ANwd5YRBMEo8v5s98KdBFtCg== X-Received: by 2002:a63:29c8:: with SMTP id p191mr3380288pgp.197.1553298621841; Fri, 22 Mar 2019 16:50:21 -0700 (PDT) Received: from localhost ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id b8sm9905445pgq.33.2019.03.22.16.50.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 22 Mar 2019 16:50:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20190315200759.139479-1-swboyd@chromium.org> From: Stephen Boyd Subject: Re: [PATCH] genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent() To: Thomas Gleixner Message-ID: <155329862018.20095.14024385652448015564@swboyd.mtv.corp.google.com> User-Agent: alot/0.8 Date: Fri, 22 Mar 2019 16:50:20 -0700 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190322_165023_441267_8B6BC059 X-CRM114-Status: GOOD ( 20.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lina Iyer Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Thomas Gleixner (2019-03-21 02:26:26) > On Fri, 15 Mar 2019, Stephen Boyd wrote: > > > This function returns an error if a child interrupt controller calls > > irq_chip_set_wake_parent() but that parent interrupt controller has the > > IRQCHIP_SKIP_SET_WAKE flag. Let's return 0 for success instead because > > there isn't anything to do. > > > > There's also the possibility that a parent indicates that we should skip > > it, but the grandparent has an .irq_set_wake callback. Let's iterate > > through the parent chain as long as the IRQCHIP_SKIP_SET_WAKE flag isn't > > set so we can find the first parent that needs to handle the wake > > configuration. This fixes a problem on my Qualcomm sdm845 device where > > I'm trying to enable wake on an irq from the gpio controller that's a > > child of the qcom pdc interrupt controller. The qcom pdc interrupt > > controller has the IRQCHIP_SKIP_SET_WAKE flag set, and so does the > > grandparent (ARM GIC), causing this function to return a failure because > > the parent controller doesn't have the .irq_set_wake callback set. > > It took me some time to distangle that changelog.... and I don't think that > this is the right thing to do. Yes, your diagram would be a useful addition to the commit text. > > set_irq_wake_real() returns 0 when the topmost chip has SKIP_SET_WAKE set. Just to confirm, the topmost chip would be chip B or chip C below? > > So let's assume we have the following chains: > > chip A -> chip B > > chip A -> chip B -> chip C > > chip A has SKIP_SET_WAKE not set > chip B has SKIP_SET_WAKE set > chip C has SKIP_SET_WAKE not set and invokes irq_chip_set_wake_parent() > > Now assume we have interrupt X connected to chip B and interrupt Y > connected to chip C. > > If irq_set_wake() is called for interrupt X, then the function returns > without trying to invoke the set_wake() callback of chip A. It's not clear to me that having SKIP_SET_WAKE set means "completely ignore set wake for irqs from this domain" vs. "skip setting wake here because the .irq_set_wake() is intentionally omitted for this chip". Reading Santosh's reasoning in commit 60f96b41f71d ("genirq: Add IRQCHIP_SKIP_SET_WAKE flag") just further confuses me because it sounds like the latter. > > If irq_set_wake() is called for interrupt Y, irq_chip_set_wake_parent() is > invoked from chip C which then skips chip B, but tries to invoke the > callback on chip A. > > That's inconsistent and changes the existing behaviour. So IMO, the right > thing to do is to return 0 from irq_chip_set_wake_parent() when the parent > has SKIP_SET_WAKE set and not to try to follow the whole chain. That should > fix your problem nicely w/o changing behaviour. Ok. I understand that with hierarchical chips you want it to be explicit in the code that a parent chip needs to be called or not. This works for me, and it's actually how I had originally solved this problem. Will you merge your patch or do you want me to resend it with some updated commit text? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel