linux-kernel - Re: [PATCH] pci: mediatek: fix warning in msi.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87lfflti8q.wl-maz@kernel.org>
Date:   Sun, 01 Nov 2020 11:43:33 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     frank-w@...lic-files.de
Cc:     linux-mediatek@...ts.infradead.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Frank Wunderlich <linux@...web.de>,
        linux-kernel@...r.kernel.org, Ryder Lee <ryder.lee@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH] pci: mediatek: fix warning in msi.h

On Sun, 01 Nov 2020 09:25:04 +0000,
Frank Wunderlich <frank-w@...lic-files.de> wrote:
> 
> Am 31. Oktober 2020 22:49:14 MEZ schrieb Thomas Gleixner <tglx@...utronix.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.