From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> To: Nikita Yushchenko <nikita.yoush@cogentembedded.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org, Simon Horman <horms@verge.net.au>, Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org Cc: artemi.ivanov@cogentembedded.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Date: Fri, 30 Dec 2016 12:46:49 +0300 [thread overview] Message-ID: <b83c353c-c054-4378-9308-e625c460bdd9@cogentembedded.com> (raw) In-Reply-To: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> Hello! On 12/29/2016 11:45 PM, Nikita Yushchenko wrote: > It is possible that PCI device supports 64-bit DMA addressing, and thus > it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host Its. > bridge has limitations on inbound transactions addressing. Example of > such setup is NVME Isn't it called NVMe? > SSD device connected to RCAR PCIe controller. R=Car. > Previously there was attempt to handle this via bus notifier: after > driver is attached to PCI device, bridge driver gets notifier callback, > and resets dma_mask from there. However, this is racy: PCI device driver > could already allocate buffers and/or start i/o in probe routine. > In NVME case, i/o is started in workqueue context, and this race gives > "sometimes works, sometimes not" effect. > > Proper solution should make driver's dma_set_mask() call to fail if host > bridge can't support mask being set. > > This patch makes __swiotlb_dma_supported() to check mask being set for "To" not needed here. > PCI device against dma_mask of struct device corresponding to PCI host > bridge (one with name "pciXXXX:YY"), if that dma_mask is set. > > This is the least destructive approach: currently dma_mask of that device > object is not used anyhow, thus all existing setups will work as before, > and modification is required only in actually affected components - > driver of particular PCI host bridge, and dma_map_ops of particular > platform. > > Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> > --- > arch/arm64/mm/dma-mapping.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c > index 290a84f..49645277 100644 > --- a/arch/arm64/mm/dma-mapping.c > +++ b/arch/arm64/mm/dma-mapping.c [...] > @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, > > static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) > { > +#ifdef CONFIG_PCI > + if (dev_is_pci(hwdev)) { > + struct pci_dev *pdev = to_pci_dev(hwdev); > + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus); > + > + if (br->dev.dma_mask && (*br->dev.dma_mask) && > + (mask & (*br->dev.dma_mask)) != mask) Hum, inner parens not necessary? [...] MBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: sergei.shtylyov@cogentembedded.com (Sergei Shtylyov) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Date: Fri, 30 Dec 2016 12:46:49 +0300 [thread overview] Message-ID: <b83c353c-c054-4378-9308-e625c460bdd9@cogentembedded.com> (raw) In-Reply-To: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> Hello! On 12/29/2016 11:45 PM, Nikita Yushchenko wrote: > It is possible that PCI device supports 64-bit DMA addressing, and thus > it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host Its. > bridge has limitations on inbound transactions addressing. Example of > such setup is NVME Isn't it called NVMe? > SSD device connected to RCAR PCIe controller. R=Car. > Previously there was attempt to handle this via bus notifier: after > driver is attached to PCI device, bridge driver gets notifier callback, > and resets dma_mask from there. However, this is racy: PCI device driver > could already allocate buffers and/or start i/o in probe routine. > In NVME case, i/o is started in workqueue context, and this race gives > "sometimes works, sometimes not" effect. > > Proper solution should make driver's dma_set_mask() call to fail if host > bridge can't support mask being set. > > This patch makes __swiotlb_dma_supported() to check mask being set for "To" not needed here. > PCI device against dma_mask of struct device corresponding to PCI host > bridge (one with name "pciXXXX:YY"), if that dma_mask is set. > > This is the least destructive approach: currently dma_mask of that device > object is not used anyhow, thus all existing setups will work as before, > and modification is required only in actually affected components - > driver of particular PCI host bridge, and dma_map_ops of particular > platform. > > Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> > --- > arch/arm64/mm/dma-mapping.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c > index 290a84f..49645277 100644 > --- a/arch/arm64/mm/dma-mapping.c > +++ b/arch/arm64/mm/dma-mapping.c [...] > @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, > > static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) > { > +#ifdef CONFIG_PCI > + if (dev_is_pci(hwdev)) { > + struct pci_dev *pdev = to_pci_dev(hwdev); > + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus); > + > + if (br->dev.dma_mask && (*br->dev.dma_mask) && > + (mask & (*br->dev.dma_mask)) != mask) Hum, inner parens not necessary? [...] MBR, Sergei
next prev parent reply other threads:[~2016-12-30 9:46 UTC|newest] Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-29 20:45 [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Nikita Yushchenko 2016-12-29 20:45 ` Nikita Yushchenko 2016-12-29 20:45 ` [PATCH 2/2] rcar-pcie: set host bridge's " Nikita Yushchenko 2016-12-29 20:45 ` Nikita Yushchenko 2016-12-29 21:18 ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit " Arnd Bergmann 2017-02-16 16:12 ` Arnd Bergmann 2016-12-29 21:18 ` Arnd Bergmann 2016-12-30 9:46 ` Sergei Shtylyov [this message] 2016-12-30 9:46 ` Sergei Shtylyov 2016-12-30 10:06 ` Sergei Shtylyov 2016-12-30 10:06 ` Sergei Shtylyov 2017-01-03 18:44 ` Will Deacon 2017-01-03 18:44 ` Will Deacon 2017-01-03 19:00 ` Nikita Yushchenko 2017-01-03 19:00 ` Nikita Yushchenko 2017-01-03 19:01 ` Nikita Yushchenko 2017-01-03 19:01 ` Nikita Yushchenko 2017-01-03 19:01 ` Nikita Yushchenko 2017-01-03 20:13 ` Grygorii Strashko 2017-01-03 20:13 ` Grygorii Strashko 2017-01-03 20:13 ` Grygorii Strashko 2017-01-03 20:23 ` Nikita Yushchenko 2017-01-03 20:23 ` Nikita Yushchenko 2017-01-03 20:23 ` Nikita Yushchenko 2017-01-03 23:13 ` Arnd Bergmann 2017-01-03 23:13 ` Arnd Bergmann 2017-01-03 23:13 ` Arnd Bergmann 2017-01-04 6:24 ` Nikita Yushchenko 2017-01-04 6:24 ` Nikita Yushchenko 2017-01-04 6:24 ` Nikita Yushchenko 2017-01-04 13:29 ` Arnd Bergmann 2017-01-04 13:29 ` Arnd Bergmann 2017-01-04 13:29 ` Arnd Bergmann 2017-01-04 14:30 ` Nikita Yushchenko 2017-01-04 14:30 ` Nikita Yushchenko 2017-01-04 14:30 ` Nikita Yushchenko 2017-01-04 14:46 ` Arnd Bergmann 2017-01-04 14:46 ` Arnd Bergmann 2017-01-04 15:29 ` Nikita Yushchenko 2017-01-04 15:29 ` Nikita Yushchenko 2017-01-04 15:29 ` Nikita Yushchenko 2017-01-06 11:10 ` Arnd Bergmann 2017-01-06 11:10 ` Arnd Bergmann 2017-01-06 11:10 ` Arnd Bergmann 2017-01-06 13:47 ` Nikita Yushchenko 2017-01-06 13:47 ` Nikita Yushchenko 2017-01-06 13:47 ` Nikita Yushchenko 2017-01-06 14:38 ` [PATCH] arm64: do not set dma masks that device connection can't handle Nikita Yushchenko 2017-01-06 14:38 ` Nikita Yushchenko 2017-01-06 14:45 ` Nikita Yushchenko 2017-01-06 14:45 ` Nikita Yushchenko 2017-01-08 7:09 ` Sergei Shtylyov 2017-01-08 7:09 ` Sergei Shtylyov 2017-01-09 6:56 ` Nikita Yushchenko 2017-01-09 6:56 ` Nikita Yushchenko 2017-01-09 14:05 ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Arnd Bergmann 2017-01-09 14:05 ` Arnd Bergmann 2017-01-09 14:05 ` Arnd Bergmann 2017-01-09 20:34 ` Nikita Yushchenko 2017-01-09 20:34 ` Nikita Yushchenko 2017-01-09 20:34 ` Nikita Yushchenko 2017-01-09 20:34 ` Nikita Yushchenko 2017-01-09 20:57 ` Christoph Hellwig 2017-01-09 20:57 ` Christoph Hellwig 2017-01-09 20:57 ` Christoph Hellwig 2017-01-09 20:57 ` Christoph Hellwig 2017-01-10 6:47 ` NVMe vs DMA addressing limitations Nikita Yushchenko 2017-01-10 7:07 ` Christoph Hellwig 2017-01-10 7:07 ` Christoph Hellwig 2017-01-10 7:07 ` Christoph Hellwig 2017-01-10 7:07 ` Christoph Hellwig 2017-01-10 7:31 ` Nikita Yushchenko 2017-01-10 7:31 ` Nikita Yushchenko 2017-01-10 7:31 ` Nikita Yushchenko 2017-01-10 7:31 ` Nikita Yushchenko 2017-01-10 11:01 ` Arnd Bergmann 2017-01-10 11:01 ` Arnd Bergmann 2017-01-10 11:01 ` Arnd Bergmann 2017-01-10 11:01 ` Arnd Bergmann 2017-01-10 14:48 ` Christoph Hellwig 2017-01-10 14:48 ` Christoph Hellwig 2017-01-10 14:48 ` Christoph Hellwig 2017-01-10 14:48 ` Christoph Hellwig 2017-01-10 15:02 ` Arnd Bergmann 2017-01-10 15:02 ` Arnd Bergmann 2017-01-10 15:02 ` Arnd Bergmann 2017-01-10 15:02 ` Arnd Bergmann 2017-01-12 10:09 ` Sagi Grimberg 2017-01-12 10:09 ` Sagi Grimberg 2017-01-12 10:09 ` Sagi Grimberg 2017-01-12 10:09 ` Sagi Grimberg 2017-01-12 11:56 ` Arnd Bergmann 2017-01-12 11:56 ` Arnd Bergmann 2017-01-12 11:56 ` Arnd Bergmann 2017-01-12 11:56 ` Arnd Bergmann 2017-01-12 13:07 ` Christoph Hellwig 2017-01-12 13:07 ` Christoph Hellwig 2017-01-12 13:07 ` Christoph Hellwig 2017-01-12 13:07 ` Christoph Hellwig 2017-01-10 10:54 ` Arnd Bergmann 2017-01-10 10:54 ` Arnd Bergmann 2017-01-10 10:54 ` Arnd Bergmann 2017-01-10 10:54 ` Arnd Bergmann 2017-01-10 10:47 ` [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Arnd Bergmann 2017-01-10 10:47 ` Arnd Bergmann 2017-01-10 10:47 ` Arnd Bergmann 2017-01-10 10:47 ` Arnd Bergmann 2017-01-10 14:44 ` Christoph Hellwig 2017-01-10 14:44 ` Christoph Hellwig 2017-01-10 14:44 ` Christoph Hellwig 2017-01-10 14:44 ` Christoph Hellwig 2017-01-10 15:00 ` Arnd Bergmann 2017-01-10 15:00 ` Arnd Bergmann 2017-01-10 15:00 ` Arnd Bergmann 2017-01-10 15:00 ` Arnd Bergmann
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=b83c353c-c054-4378-9308-e625c460bdd9@cogentembedded.com \ --to=sergei.shtylyov@cogentembedded.com \ --cc=arnd@arndb.de \ --cc=artemi.ivanov@cogentembedded.com \ --cc=bhelgaas@google.com \ --cc=catalin.marinas@arm.com \ --cc=horms@verge.net.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=nikita.yoush@cogentembedded.com \ --cc=will.deacon@arm.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: linkBe 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.