linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Vidya Sagar <vidyas@nvidia.com>,
	jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
	lorenzo.pieralisi@arm.com, bhelgaas@google.com, robh@kernel.org,
	treding@nvidia.com, jonathanh@nvidia.com
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com
Subject: Re: [PATCH] PCI: dwc: Set 32-bit DMA mask for MSI target address allocation
Date: Mon, 7 Dec 2020 20:32:16 +0000	[thread overview]
Message-ID: <a5d8c24b-c605-8753-b022-ab959cf52340@arm.com> (raw)
In-Reply-To: <20201117165312.25847-1-vidyas@nvidia.com>

On 2020-11-17 16:53, Vidya Sagar wrote:
> Set DMA mask to 32-bit while allocating the MSI target address so that
> the address is usable for both 32-bit and 64-bit MSI capable devices.
> Throw a warning if it fails to set the mask to 32-bit to alert that
> devices that are only 32-bit MSI capable may not work properly.

This is slightly wacky, but no more so than the rest of the not-DMA 
shenanigans here... Ultimately it probably is the least-worst way to 
avoid the issue, so in terms of functionality,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> Given the other patch that I've pushed to the MSI sub-system
> http://patchwork.ozlabs.org/project/linux-pci/patch/20201117145728.4516-1-vidyas@nvidia.com/
> which is going to catch any mismatch between MSI capability (32-bit) of the
> device and system's inability to allocate the required MSI target address,
> I'm not sure how much sense is this patch going to be make. But, I can
> certainly say that if the memory allocation mechanism gives the addresses
> from 64-bit pool by default, this patch at least makes sure that MSI target
> address is allocated from 32-bit pool.

Note that this doesn't change where anything is allocated as such, it 
just means that on systems with most of their RAM above 4GB, those few 
bytes of private data that you map "for free" will be copied into the 
SWIOTLB buffer and hog 2KB of its typical 64MB capacity effectively for 
ever.

>   drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 44c2a6572199..e6a230eddf66 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -388,6 +388,14 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   							    dw_chained_msi_isr,
>   							    pp);
>   
> +			ret = dma_set_mask(pci->dev, DMA_BIT_MASK(32));
> +			if (!ret) {
> +				dev_warn(pci->dev,
> +					 "Failed to set DMA mask to 32-bit. "
> +					 "Devices with only 32-bit MSI support"
> +					 " may not work properly\n");
> +			}

Ironically, the only real reason for that dma_set_mask() to ever fail is 
if the system had no 32-bit addressable memory, in which case you could 
likely pick any 32-bit doorbell address with impunity, just not via this 
mechanism (although whether it would be worthwhile is another matter).

Robin.

> +
>   			pp->msi_data = dma_map_single_attrs(pci->dev, &pp->msi_msg,
>   						      sizeof(pp->msi_msg),
>   						      DMA_FROM_DEVICE,
> 

  parent reply	other threads:[~2020-12-07 20:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 16:53 [PATCH] PCI: dwc: Set 32-bit DMA mask for MSI target address allocation Vidya Sagar
2020-12-03  5:02 ` Vidya Sagar
2020-12-07 20:32 ` Robin Murphy [this message]
2020-12-10 11:48 ` Lorenzo Pieralisi

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=a5d8c24b-c605-8753-b022-ab959cf52340@arm.com \
    --to=robin.murphy@arm.com \
    --cc=bhelgaas@google.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=kthota@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mmaddireddy@nvidia.com \
    --cc=robh@kernel.org \
    --cc=sagar.tv@gmail.com \
    --cc=treding@nvidia.com \
    --cc=vidyas@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).