From patchwork Wed Jun 12 05:16:05 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Benjamin Herrenschmidt X-Patchwork-Id: 10988465 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 063D513AF for ; Wed, 12 Jun 2019 05:16:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DD7CF28897 for ; Wed, 12 Jun 2019 05:16:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D192D288CB; Wed, 12 Jun 2019 05:16:31 +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=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C027328897 for ; Wed, 12 Jun 2019 05:16:30 +0000 (UTC) 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:Mime-Version:Date:To:From:Subject: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=4U8qEweRlphx7FkYAheEYu+XdiVVLhFTQgM7YI/7y7I=; b=ivTzpYWd4kIqj6 /rBAarihV2XoDLhVW1tt26ErMeyZ9ko9LIjbnbspuqpFFQ1ks9qOqrwmBUAyAyPakMYCmefy2kDZW hAskyZOevrYj//P3babSD4gQQhYvOj2DliUjdD8y8ppiR3pS4KZpqHoIfIFBGVy5N5+xACTjCR6wk kCl68erFvVDYplYzut3gmTrQRcmNR83gweBKDhuBd+KxpHr244Zehkw/NiqvAVjiUCZ9xINSiouiL hm0pkkldv9T4NXnCSe0+sm1yUHgsTG9wpRPkZBcyw6QZ468zytz9UFpkGzP9yvLxtyJVylZYknyjB gD4bMUaj+zRn2XhkQiGQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1havcV-0006Lf-WF; Wed, 12 Jun 2019 05:16:24 +0000 Received: from gate.crashing.org ([63.228.1.57]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1havcR-0006L2-Qm for linux-arm-kernel@lists.infradead.org; Wed, 12 Jun 2019 05:16:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x5C5G5tU001179; Wed, 12 Jun 2019 00:16:07 -0500 Message-ID: Subject: [PATCH+DISCUSSION] irqchip: armada-370-xp: Remove redundant ops assignment From: Benjamin Herrenschmidt To: Thomas Petazzoni Date: Wed, 12 Jun 2019 15:16:05 +1000 X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190611_221621_866733_EF23A127 X-CRM114-Status: GOOD ( 10.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gregory CLEMENT , Marc Zyngier , "linux-kernel@vger.kernel.org" , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP pci_msi_create_irq_domain -> pci_msi_domain_update_chip_ops will set those two already since the driver sets MSI_FLAG_USE_DEF_CHIP_OPS Signed-off-by: Benjamin Herrenschmidt --- [UNTESTED] Just something I noticed while browsing through those drivers in search of ways to factor some of the code. That leads to a question here: Some MSI drivers such as this one (or any using the defaults mask/unmask provided by drivers/pci/msi.c) only call the PCI MSI mask/unmask functions. Some other drivers call those PCI function but *also* call the parent mask/unmask (giv-v2m for example) which generally is the inner domain which just itself forwards to its own parent. Is there any preference for doing it one way or the other ? I can see that in cases where the device doesn't support MSI masking, calling the parent could be useful but we don't know that at the moment in the corresponding code. It feels like something we should consolidate (and remove code from drivers). For example, the defaults in drivers/pci/msi.c could always call the parent if it exists and has a mask/unmask callback. Opinions ? I'm happy to produce patches once we agree... diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c index c9bdc5221b82..911230f28e2d 100644 --- a/drivers/irqchip/irq-armada-370-xp.c +++ b/drivers/irqchip/irq-armada-370-xp.c @@ -197,8 +197,6 @@ static void armada_370_xp_irq_unmask(struct irq_data *d) static struct irq_chip armada_370_xp_msi_irq_chip = { .name = "MPIC MSI", - .irq_mask = pci_msi_mask_irq, - .irq_unmask = pci_msi_unmask_irq, }; static struct msi_domain_info armada_370_xp_msi_domain_info = {