From: William McVicker <willmcvicker@google.com>
To: Ajay Agarwal <ajayagarwal@google.com>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Manu Gautam" <manugautam@google.com>,
"Sajid Dalvi" <sdalvi@google.com>,
"Serge Semin" <fancer.lancer@gmail.com>,
"Robin Murphy" <robin.murphy@arm.com>,
linux-pci@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v6] PCI: dwc: Strengthen the MSI address allocation logic
Date: Wed, 21 Feb 2024 15:13:52 -0800 [thread overview]
Message-ID: <ZdaDsN675hiS6zhY@google.com> (raw)
In-Reply-To: <20240221153840.1789979-1-ajayagarwal@google.com>
On 02/21/2024, Ajay Agarwal wrote:
> There can be platforms that do not use/have 32-bit DMA addresses.
> The current implementation of 32-bit IOVA allocation can fail for
> such platforms, eventually leading to the probe failure.
>
> Try to allocate a 32-bit msi_data. If this allocation fails,
> attempt a 64-bit address allocation. Please note that if the
> 64-bit MSI address is allocated, then the EPs supporting 32-bit
> MSI address only will not work.
>
> Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
> ---
> Changelog since v5:
> - Initialize temp variable 'msi_vaddr' to NULL
> - Remove redundant print and check
>
> Changelog since v4:
> - Remove the 'DW_PCIE_CAP_MSI_DATA_SET' flag
> - Refactor the comments and msi_data allocation logic
>
> Changelog since v3:
> - Add a new controller cap flag 'DW_PCIE_CAP_MSI_DATA_SET'
> - Refactor the comments and print statements
>
> Changelog since v2:
> - If the vendor driver has setup the msi_data, use the same
>
> Changelog since v1:
> - Use reserved memory, if it exists, to setup the MSI data
> - Fallback to 64-bit IOVA allocation if 32-bit allocation fails
>
> .../pci/controller/dwc/pcie-designware-host.c | 21 ++++++++++++-------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index d5fc31f8345f..d15a5c2d5b48 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -328,7 +328,7 @@ static int dw_pcie_msi_host_init(struct dw_pcie_rp *pp)
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> struct device *dev = pci->dev;
> struct platform_device *pdev = to_platform_device(dev);
> - u64 *msi_vaddr;
> + u64 *msi_vaddr = NULL;
> int ret;
> u32 ctrl, num_ctrls;
>
> @@ -379,15 +379,20 @@ static int dw_pcie_msi_host_init(struct dw_pcie_rp *pp)
> * memory.
> */
> ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> - if (ret)
> - dev_warn(dev, "Failed to set DMA mask to 32-bit. Devices with only 32-bit MSI support may not work properly\n");
> + if (!ret)
> + msi_vaddr = dmam_alloc_coherent(dev, sizeof(u64), &pp->msi_data,
> + GFP_KERNEL);
>
> - msi_vaddr = dmam_alloc_coherent(dev, sizeof(u64), &pp->msi_data,
> - GFP_KERNEL);
> if (!msi_vaddr) {
> - dev_err(dev, "Failed to alloc and map MSI data\n");
> - dw_pcie_free_msi(pp);
> - return -ENOMEM;
> + dev_warn(dev, "Failed to allocate 32-bit MSI address\n");
> + dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
> + msi_vaddr = dmam_alloc_coherent(dev, sizeof(u64), &pp->msi_data,
> + GFP_KERNEL);
> + if (!msi_vaddr) {
> + dev_err(dev, "Failed to allocate MSI address\n");
> + dw_pcie_free_msi(pp);
> + return -ENOMEM;
> + }
> }
>
> return 0;
> --
> 2.44.0.rc0.258.g7320e95886-goog
>
Thanks for working through all the kinks, Ajay! The patch looks good to me.
I tested it on my Pixel 8 with ZONE_DMA32 disabled. I wasn't able to reproduce
the case where there was no 32-bit addresses available on boot, but I did
artificially test it by commenting out the first call to dmam_alloc_coherent()
to exercise the fallback case where msi_vaddr is NULL and the 64-bit coherent
mask is set. In both cases, I verified the PCIe device probes successfully with
this change and wifi works.
Feel free to include,
Reviewed-by: Will McVicker <willmcvicker@google.com>
Tested-by: Will McVicker <willmcvicker@google.com>
Thanks,
Will
next prev parent reply other threads:[~2024-02-21 23:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-21 15:38 [PATCH v6] PCI: dwc: Strengthen the MSI address allocation logic Ajay Agarwal
2024-02-21 17:32 ` Serge Semin
2024-02-21 23:13 ` William McVicker [this message]
2024-02-27 14:45 ` Manivannan Sadhasivam
2024-03-10 18:15 ` Krzysztof Wilczyński
2024-03-11 16:58 ` Bjorn Helgaas
2024-03-12 13:52 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZdaDsN675hiS6zhY@google.com \
--to=willmcvicker@google.com \
--cc=ajayagarwal@google.com \
--cc=bhelgaas@google.com \
--cc=fancer.lancer@gmail.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=kernel-team@android.com \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=manugautam@google.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sdalvi@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.