All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <mani@kernel.org>
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>,
	"William McVicker" <willmcvicker@google.com>,
	"Serge Semin" <fancer.lancer@gmail.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v4] PCI: dwc: Strengthen the MSI address allocation logic
Date: Wed, 14 Feb 2024 12:38:42 +0530	[thread overview]
Message-ID: <20240214070842.GE4618@thinkpad> (raw)
In-Reply-To: <20240214053415.3360897-1-ajayagarwal@google.com>

On Wed, Feb 14, 2024 at 11:04:15AM +0530, Ajay Agarwal wrote:
> There can be platforms that do not use/have 32-bit DMA addresses
> but want to enumerate endpoints which support only 32-bit MSI
> address. The current implementation of 32-bit IOVA allocation can
> fail for such platforms, eventually leading to the probe failure.
> 
> If the vendor driver has already setup the MSI address using
> some mechanism, use the same. This method can be used by the
> platforms described above to support EPs they wish to. Such
> drivers should set the DW_PCIE_CAP_MSI_DATA_SET flag.
> 
> Else, try to allocate a 32-bit IOVA. Additionally, if this
> allocation also fails, attempt a 64-bit allocation for probe to
> be successful. If the 64-bit MSI address is allocated, then the
> EPs supporting 32-bit MSI address will not work.
> 
> Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
> ---
> 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  | 18 +++++++++++++++---
>  drivers/pci/controller/dwc/pcie-designware.h   |  1 +
>  2 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index d5fc31f8345f..06ee2e5deebc 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -373,11 +373,17 @@ static int dw_pcie_msi_host_init(struct dw_pcie_rp *pp)
>  	 * peripheral PCIe devices may lack 64-bit message support. In
>  	 * order not to miss MSI TLPs from those devices the MSI target
>  	 * address has to be within the lowest 4GB.
> +	 * Permit the platforms to override the MSI target address if they
> +	 * have a free PCIe-bus memory specifically reserved for that. Such
> +	 * platforms should set the 'DW_PCIE_CAP_MSI_DATA_SET' cap flag.
>  	 *
>  	 * Note until there is a better alternative found the reservation is
>  	 * done by allocating from the artificially limited DMA-coherent
>  	 * memory.
>  	 */

Now the above comments are misplaced. Please move the comments related to
setting coherent mask just above the dma_set_coherent_mask() API and keep the
flag related comments here.

> +	if (dw_pcie_cap_is(pci, MSI_DATA_SET))

Who is setting this flag? You should not add code when there are no in-kernel
consumers.

> +		return 0;
> +
>  	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");
> @@ -385,9 +391,15 @@ static int dw_pcie_msi_host_init(struct dw_pcie_rp *pp)
>  	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 configure 32-bit MSI address. Devices with only 32-bit MSI support may not work properly\n");

This is a duplicated error log.

> +		dma_set_coherent_mask(dev, DMA_BIT_MASK(64));

Is there a guarantee that this will never fail?

- Mani

-- 
மணிவண்ணன் சதாசிவம்

  reply	other threads:[~2024-02-14  7:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14  5:34 [PATCH v4] PCI: dwc: Strengthen the MSI address allocation logic Ajay Agarwal
2024-02-14  7:08 ` Manivannan Sadhasivam [this message]
2024-02-21  5:47   ` Ajay Agarwal

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=20240214070842.GE4618@thinkpad \
    --to=mani@kernel.org \
    --cc=ajayagarwal@google.com \
    --cc=bhelgaas@google.com \
    --cc=fancer.lancer@gmail.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manugautam@google.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sdalvi@google.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.