From: Rob Herring <robh@kernel.org>
To: Will McVicker <willmcvicker@google.com>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
kernel-team@android.com, "Vidya Sagar" <vidyas@nvidia.com>,
"kernel test robot" <lkp@intel.com>,
"Isaac J . Manjarres" <isaacmanjarres@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] PCI: dwc: drop dependency on ZONE_DMA32
Date: Wed, 10 Aug 2022 15:27:16 -0600 [thread overview]
Message-ID: <20220810212716.GA557589-robh@kernel.org> (raw)
In-Reply-To: <20220810183536.1630940-2-willmcvicker@google.com>
On Wed, Aug 10, 2022 at 06:35:34PM +0000, Will McVicker wrote:
> Re-work the msi_msg DMA allocation logic to use dma_alloc_coherent()
> which uses the coherent DMA mask to try and return an allocation within
> the DMA mask limits. This allows kernel configurations that disable
> ZONE_DMA32 to continue supporting a 32-bit DMA mask. Without this patch,
> the PCIe host device will fail to probe when ZONE_DMA32 is disabled.
>
> Fixes: 35797e672ff0 ("PCI: dwc: Fix MSI msi_msg DMA mapping")
> Reported-by: Isaac J. Manjarres <isaacmanjarres@google.com>
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
> .../pci/controller/dwc/pcie-designware-host.c | 23 ++++++++-----------
> 1 file changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 7746f94a715f..8f2222f51671 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -272,9 +272,9 @@ static void dw_pcie_free_msi(struct dw_pcie_rp *pp)
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> struct device *dev = pci->dev;
>
> - dma_unmap_page(dev, pp->msi_data, PAGE_SIZE, DMA_FROM_DEVICE);
> - if (pp->msi_page)
> - __free_page(pp->msi_page);
> + dma_free_coherent(dev, PAGE_SIZE, pp->msi_page, pp->msi_data);
> + pp->msi_data = 0;
> + pp->msi_page = NULL;
> }
> }
>
> @@ -375,22 +375,17 @@ static int dw_pcie_msi_host_init(struct dw_pcie_rp *pp)
> dw_chained_msi_isr, pp);
> }
>
> - ret = dma_set_mask(dev, DMA_BIT_MASK(32));
> + ret = dma_set_mask_and_coherent(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");
>
> - pp->msi_page = alloc_page(GFP_DMA32);
> - pp->msi_data = dma_map_page(dev, pp->msi_page, 0,
> - PAGE_SIZE, DMA_FROM_DEVICE);
> - ret = dma_mapping_error(dev, pp->msi_data);
> - if (ret) {
> - dev_err(pci->dev, "Failed to map MSI data\n");
> - __free_page(pp->msi_page);
> - pp->msi_page = NULL;
> + pp->msi_page = dma_alloc_coherent(dev, PAGE_SIZE, &pp->msi_data,
> + GFP_KERNEL);
You can use the managed version, dmam_alloc_coherent(), and avoid the
freeing yourself. Also with that, I think you don't need 'msi_page'?
Also, no need to alloc a whole page. A u32 or u64? should be fine. The
write never makes it to memory, so doesn't really matter.
> + if (!pp->msi_page) {
> + dev_err(dev, "Failed to alloc and map MSI data\n");
> pp->msi_data = 0;
> dw_pcie_free_msi(pp);
> -
> - return ret;
> + return -ENOMEM;
> }
>
> return 0;
> --
> 2.37.1.559.g78731f0fdb-goog
>
next prev parent reply other threads:[~2022-08-10 21:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 18:35 [PATCH v2 0/2] PCI: dwc: Add support for 64-bit MSI target addresses Will McVicker
2022-08-10 18:35 ` [PATCH v2 1/2] PCI: dwc: drop dependency on ZONE_DMA32 Will McVicker
2022-08-10 21:27 ` Rob Herring [this message]
2022-08-10 23:09 ` William McVicker
2022-08-10 18:35 ` [PATCH v2 2/2] PCI: dwc: add support for 64-bit MSI target address Will McVicker
2022-08-10 21:30 ` Rob Herring
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=20220810212716.GA557589-robh@kernel.org \
--to=robh@kernel.org \
--cc=bhelgaas@google.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=isaacmanjarres@google.com \
--cc=jingoohan1@gmail.com \
--cc=kernel-team@android.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lpieralisi@kernel.org \
--cc=vidyas@nvidia.com \
--cc=willmcvicker@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.