Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 01 Nov 2020 11:43:33 +0000
Message-ID: <87lfflti8q.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     frank-w@public-files.de
Cc:     linux-mediatek@lists.infradead.org,
        Thomas Gleixner <tglx@linutronix.de>,
        Frank Wunderlich <linux@fw-web.de>,
        linux-kernel@vger.kernel.org, Ryder Lee <ryder.lee@mediatek.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH] pci: mediatek: fix warning in msi.h
In-Reply-To: <EC02022C-64CF-4F4B-A0A2-215A0A49E826@public-files.de>
References: <20201031140330.83768-1-linux@fw-web.de>
        <878sbm9icl.fsf@nanos.tec.linutronix.de>
        <EC02022C-64CF-4F4B-A0A2-215A0A49E826@public-files.de>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26.3
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Sun, 01 Nov 2020 09:25:04 +0000,
Frank Wunderlich <frank-w@public-files.de> wrote:
> 
> Am 31. Oktober 2020 22:49:14 MEZ schrieb Thomas Gleixner <tglx@linutronix.de>:
> 
> >That's not a fix. It's just supressing the warning.
> 
> Ok sorry
> 
> >So it needs to be figured out why the domain association is not there.
> 
> It looks like for mt7623 there is no msi domain setup (done via
> mtk_pcie_setup_irq callback + mtk_pcie_init_irq_domain) in mtk pcie
> driver.

Does this mean that this SoC never handled MSIs the first place? Which
would explain the warning, as there is no MSI domain registered for
the device, and we end-up falling back to arch_setup_msi_irqs().

If this system truly is unable to handle MSIs, one potential
workaround would be to register a PCI-MSI domain that would always
fail its allocation with -ENOSPC. It is really ugly, but would keep
the horror localised. See the patchlet below, which I can't test.

If this situation is more common than we expect, we may need something
in core code instead.

	M.

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index cf4c18f0c25a..52758b546d40 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -151,6 +151,7 @@ struct mtk_pcie_port;
 struct mtk_pcie_soc {
 	bool need_fix_class_id;
 	bool need_fix_device_id;
+	bool no_msi;
 	unsigned int device_id;
 	struct pci_ops *ops;
 	int (*startup)(struct mtk_pcie_port *port);
@@ -435,6 +436,9 @@ static int mtk_pcie_irq_domain_alloc(struct irq_domain *domain, unsigned int vir
 	struct mtk_pcie_port *port = domain->host_data;
 	unsigned long bit;
 
+	if (port->pcie->soc->no_msi)
+		return -ENOSPC;
+
 	WARN_ON(nr_irqs != 1);
 	mutex_lock(&port->lock);
 
@@ -966,11 +970,13 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
 	port->slot = slot;
 	port->pcie = pcie;
 
-	if (pcie->soc->setup_irq) {
+	if (pcie->soc->setup_irq)
 		err = pcie->soc->setup_irq(port, node);
-		if (err)
-			return err;
-	}
+	else
+		err = mtk_pcie_allocate_msi_domains(port);
+
+	if (err)
+		return err;
 
 	INIT_LIST_HEAD(&port->list);
 	list_add_tail(&port->list, &pcie->ports);
@@ -1173,6 +1179,7 @@ static const struct dev_pm_ops mtk_pcie_pm_ops = {
 };
 
 static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
+	.no_msi = true,
 	.ops = &mtk_pcie_ops,
 	.startup = mtk_pcie_startup_port,
 };

-- 
Without deviation from the norm, progress is not possible.