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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 5A5C8C4338F for ; Sun, 22 Aug 2021 22:18:27 +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 14D9B6125F for ; Sun, 22 Aug 2021 22:18:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 14D9B6125F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7liQjEoinMQoSdFA2h2NgHI6bDFJci3JFup0IZPHmOs=; b=JuKFXWMkUR7h6L bk7BBKETGGogR3EGkQfo8c8E6kZdiEq7APLlNC41ymQhJ5vwmi460CQPgZX2d4wIeuMRflzCkoLLN hDPVvstNj10bJ5hB+M9e21zZyeJkiIxwb1YGgdEKHxKpCWhZiDfBen1t4K/V4rs2laFO8qmPOVrzB qMDWDuxP/2gc5zicTboOy37lCCMsMSNOyqveNeVHbJRglF0V7yQoKnvviYoQpuHguchgg1pEzc5bX yoJKMOU/vzbuVjP2s6OrpRK/R/OfPqR2yN0UwNQaLioCwSo8U443sSSnox4rOuJawGZq2Z20+UJ3A aR3Do8R702qwNN3apEIw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mHvlT-00EpDp-EO; Sun, 22 Aug 2021 22:16:27 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mHvlO-00EpDP-NV for linux-arm-kernel@lists.infradead.org; Sun, 22 Aug 2021 22:16:24 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 01E5FD6E; Sun, 22 Aug 2021 15:16:16 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 504433F766; Sun, 22 Aug 2021 15:16:15 -0700 (PDT) From: Valentin Schneider To: Marc Zyngier Cc: Guenter Roeck , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] irqchip/gic: Convert to handle_strict_flow_irq() In-Reply-To: <87czqasn9u.wl-maz@kernel.org> References: <20210814194737.GA3951530@roeck-us.net> <87sfzb7jeo.mognet@arm.com> <87eeav19mc.wl-maz@kernel.org> <87k0kk7w0c.mognet@arm.com> <87czqasn9u.wl-maz@kernel.org> Date: Sun, 22 Aug 2021 23:16:10 +0100 Message-ID: <878s0t6s7p.mognet@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210822_151622_859280_3CC43221 X-CRM114-Status: GOOD ( 20.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 18/08/21 17:58, Marc Zyngier wrote: > On Tue, 17 Aug 2021 01:30:43 +0100, > Valentin Schneider wrote: >> Are we guaranteed to have >> >> .irq_ack \in {NULL, irq_chip_ack_parent} >> >> for all intermediate (!root) irqchips? I don't see why that wouldn't >> be the case, and with that in mind what you described makes sense to >> me. > > An intermediate layer is allowed to implement its own irq_ack that is > not irq_chip_ack_parent, but it then has to call irq_chip_ack_parent > itself. > Right, makes sense. > There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes > the irqchip flow to use either handle_fasteoi_ack_irq or > handle_fasteoi_mask_irq, which won't play very nicely with this. > Someone said Cavium? > Humph... I'm not familiar at all with the gpiolib irqchips, but I was under the impression those would involve chained IRQs (it does appear to be the case for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever flow was installed by the relevant driver. I can't easily grok what goes on between that gpio-thunderx.c driver and gpiolib, but since that GPIO chip has .irq_eoi = irq_chip_eoi_parent, and girq->parent_domain = irq_get_irq_data(txgpio->msix_entries[0].vector)->domain; (GPIOs hooked to MSI-X? Do I want to know?) I'm guessing it is *not* chained, which means the irq_set_handler_locked() affects the entire stack :/ [!!!] Speaking of chained IRQs, I'm now thinking this series breaks them; chained_irq_enter() + chained_irq_exit() will only issue an ->irq_eoi(), skipping the ->irq_ack()... One more thing to add to the list! >> >> > In order to restore -next into a working state, I'm temporarily >> > dropping this series. Hopefully, we can sort this out before the merge >> > window and reinstate it. >> > >> >> I'm away from any keyboard for most of this week, but I'll get to it by the >> weekend. > > No worries, enjoy your break! > I sure did, Thanks! > M. > > -- > Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 246F5C4338F for ; Sun, 22 Aug 2021 22:16:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ED1B16124B for ; Sun, 22 Aug 2021 22:16:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233451AbhHVWQ6 (ORCPT ); Sun, 22 Aug 2021 18:16:58 -0400 Received: from foss.arm.com ([217.140.110.172]:46724 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229700AbhHVWQ5 (ORCPT ); Sun, 22 Aug 2021 18:16:57 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 01E5FD6E; Sun, 22 Aug 2021 15:16:16 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 504433F766; Sun, 22 Aug 2021 15:16:15 -0700 (PDT) From: Valentin Schneider To: Marc Zyngier Cc: Guenter Roeck , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] irqchip/gic: Convert to handle_strict_flow_irq() In-Reply-To: <87czqasn9u.wl-maz@kernel.org> References: <20210814194737.GA3951530@roeck-us.net> <87sfzb7jeo.mognet@arm.com> <87eeav19mc.wl-maz@kernel.org> <87k0kk7w0c.mognet@arm.com> <87czqasn9u.wl-maz@kernel.org> Date: Sun, 22 Aug 2021 23:16:10 +0100 Message-ID: <878s0t6s7p.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/08/21 17:58, Marc Zyngier wrote: > On Tue, 17 Aug 2021 01:30:43 +0100, > Valentin Schneider wrote: >> Are we guaranteed to have >> >> .irq_ack \in {NULL, irq_chip_ack_parent} >> >> for all intermediate (!root) irqchips? I don't see why that wouldn't >> be the case, and with that in mind what you described makes sense to >> me. > > An intermediate layer is allowed to implement its own irq_ack that is > not irq_chip_ack_parent, but it then has to call irq_chip_ack_parent > itself. > Right, makes sense. > There is the bizarre case of drivers/gpio/gpio-thunderx.c that changes > the irqchip flow to use either handle_fasteoi_ack_irq or > handle_fasteoi_mask_irq, which won't play very nicely with this. > Someone said Cavium? > Humph... I'm not familiar at all with the gpiolib irqchips, but I was under the impression those would involve chained IRQs (it does appear to be the case for the pl061 GPIOs on a Juno). For those, the innermost desc would be handled via chained_irq_{enter, exit}() [!!!], and the outermost one via whatever flow was installed by the relevant driver. I can't easily grok what goes on between that gpio-thunderx.c driver and gpiolib, but since that GPIO chip has .irq_eoi = irq_chip_eoi_parent, and girq->parent_domain = irq_get_irq_data(txgpio->msix_entries[0].vector)->domain; (GPIOs hooked to MSI-X? Do I want to know?) I'm guessing it is *not* chained, which means the irq_set_handler_locked() affects the entire stack :/ [!!!] Speaking of chained IRQs, I'm now thinking this series breaks them; chained_irq_enter() + chained_irq_exit() will only issue an ->irq_eoi(), skipping the ->irq_ack()... One more thing to add to the list! >> >> > In order to restore -next into a working state, I'm temporarily >> > dropping this series. Hopefully, we can sort this out before the merge >> > window and reinstate it. >> > >> >> I'm away from any keyboard for most of this week, but I'll get to it by the >> weekend. > > No worries, enjoy your break! > I sure did, Thanks! > M. > > -- > Without deviation from the norm, progress is not possible.