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: <1604253261.22363.0.camel@mtkswgap22>
Date:   Mon, 2 Nov 2020 01:54:21 +0800
From:   Ryder Lee <ryder.lee@...iatek.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     <frank-w@...lic-files.de>, <linux-mediatek@...ts.infradead.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        Frank Wunderlich <linux@...web.de>,
        <linux-kernel@...r.kernel.org>,
        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, 2020-11-01 at 11:43 +0000, Marc Zyngier wrote:
> 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.
> 
Yea, mt7623 (mtk_pcie_soc_v1) does not support MSI, so that's a way to
handle it.

@Frank, could you help to test it?

Ryder

> 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,
>  };
>