* [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
@ 2019-11-21 9:26 Nicolas Saenz Julienne
2019-11-21 15:24 ` Christoph Hellwig
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-21 9:26 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski, Peter Zijlstra, Bjorn Helgaas,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Jens Axboe,
Joerg Roedel, Rob Herring, Frank Rowand, Christoph Hellwig,
Marek Szyprowski, Robin Murphy
Cc: Benjamin Herrenschmidt, linux-pci, linux-kernel, linux-ide,
Paul Mackerras, H. Peter Anvin, Paul Burton, Michael Ellerman,
x86, linux-acpi, Ingo Molnar, James Hogan, Len Brown, devicetree,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Rafael J. Wysocki, linux-mips, Ralf Baechle, iommu, linuxppc-dev,
Nicolas Saenz Julienne
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is already used by some architectures although
still rare.
With the introduction of the Raspberry Pi 4 we've found a new contender
for the use of bus DMA limits, as its PCIe bus can only address the
lower 3GB of memory (of a total of 4GB). This is impossible to represent
with a mask. To make things worse the device-tree code rounds non power
of two bus DMA limits to the next power of two, which is unacceptable in
this case.
In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
over the tree and treat it as such. Note that dev->bus_dma_limit should
contain the higher accesible DMA address.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since v1:
- rework ACPI code to avoid divergence with OF's
arch/mips/pci/fixup-sb1250.c | 16 ++++++++--------
arch/powerpc/sysdev/fsl_pci.c | 6 +++---
arch/x86/kernel/pci-dma.c | 2 +-
arch/x86/mm/mem_encrypt.c | 2 +-
arch/x86/pci/sta2x11-fixup.c | 2 +-
drivers/acpi/arm64/iort.c | 20 +++++++-------------
drivers/ata/ahci.c | 2 +-
drivers/iommu/dma-iommu.c | 3 +--
drivers/of/device.c | 9 +++++----
include/linux/device.h | 6 +++---
include/linux/dma-direct.h | 2 +-
include/linux/dma-mapping.h | 2 +-
kernel/dma/direct.c | 27 +++++++++++++--------------
13 files changed, 46 insertions(+), 53 deletions(-)
diff --git a/arch/mips/pci/fixup-sb1250.c b/arch/mips/pci/fixup-sb1250.c
index 8a41b359cf90..40efc990cdce 100644
--- a/arch/mips/pci/fixup-sb1250.c
+++ b/arch/mips/pci/fixup-sb1250.c
@@ -21,22 +21,22 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_PCI,
/*
* The BCM1250, etc. PCI host bridge does not support DAC on its 32-bit
- * bus, so we set the bus's DMA mask accordingly. However the HT link
+ * bus, so we set the bus's DMA limit accordingly. However the HT link
* down the artificial PCI-HT bridge supports 40-bit addressing and the
* SP1011 HT-PCI bridge downstream supports both DAC and a 64-bit bus
* width, so we record the PCI-HT bridge's secondary and subordinate bus
- * numbers and do not set the mask for devices present in the inclusive
+ * numbers and do not set the limit for devices present in the inclusive
* range of those.
*/
-struct sb1250_bus_dma_mask_exclude {
+struct sb1250_bus_dma_limit_exclude {
bool set;
unsigned char start;
unsigned char end;
};
-static int sb1250_bus_dma_mask(struct pci_dev *dev, void *data)
+static int sb1250_bus_dma_limit(struct pci_dev *dev, void *data)
{
- struct sb1250_bus_dma_mask_exclude *exclude = data;
+ struct sb1250_bus_dma_limit_exclude *exclude = data;
bool exclude_this;
bool ht_bridge;
@@ -55,7 +55,7 @@ static int sb1250_bus_dma_mask(struct pci_dev *dev, void *data)
exclude->start, exclude->end);
} else {
dev_dbg(&dev->dev, "disabling DAC for device");
- dev->dev.bus_dma_mask = DMA_BIT_MASK(32);
+ dev->dev.bus_dma_limit = DMA_BIT_MASK(32);
}
return 0;
@@ -63,9 +63,9 @@ static int sb1250_bus_dma_mask(struct pci_dev *dev, void *data)
static void quirk_sb1250_pci_dac(struct pci_dev *dev)
{
- struct sb1250_bus_dma_mask_exclude exclude = { .set = false };
+ struct sb1250_bus_dma_limit_exclude exclude = { .set = false };
- pci_walk_bus(dev->bus, sb1250_bus_dma_mask, &exclude);
+ pci_walk_bus(dev->bus, sb1250_bus_dma_limit, &exclude);
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_PCI,
quirk_sb1250_pci_dac);
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index ff0e2b156cb5..617a443d673d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -115,8 +115,8 @@ static void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
{
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
- pdev->dev.bus_dma_mask =
- hose->dma_window_base_cur + hose->dma_window_size;
+ pdev->dev.bus_dma_limit =
+ hose->dma_window_base_cur + hose->dma_window_size - 1;
}
static void setup_swiotlb_ops(struct pci_controller *hose)
@@ -135,7 +135,7 @@ static void fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
* mapping that allows addressing any RAM address from across PCI.
*/
if (dev_is_pci(dev) && dma_mask >= pci64_dma_offset * 2 - 1) {
- dev->bus_dma_mask = 0;
+ dev->bus_dma_limit = 0;
dev->archdata.dma_offset = pci64_dma_offset;
}
}
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 57de2ebff7e2..5dcedad21dff 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,7 +140,7 @@ rootfs_initcall(pci_iommu_init);
static int via_no_dac_cb(struct pci_dev *pdev, void *data)
{
- pdev->dev.bus_dma_mask = DMA_BIT_MASK(32);
+ pdev->dev.bus_dma_limit = DMA_BIT_MASK(32);
return 0;
}
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 9268c12458c8..a03614bd3e1a 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -367,7 +367,7 @@ bool force_dma_unencrypted(struct device *dev)
if (sme_active()) {
u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
- dev->bus_dma_mask);
+ dev->bus_dma_limit);
if (dma_dev_mask <= dma_enc_mask)
return true;
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 4a631264b809..c313d784efab 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -143,7 +143,7 @@ static void sta2x11_map_ep(struct pci_dev *pdev)
dev->dma_pfn_offset = PFN_DOWN(-amba_base);
- dev->bus_dma_mask = max_amba_addr;
+ dev->bus_dma_limit = max_amba_addr;
pci_set_consistent_dma_mask(pdev, max_amba_addr);
pci_set_dma_mask(pdev, max_amba_addr);
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 5a7551d060f2..33f71983e001 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1057,8 +1057,8 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
*/
void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
{
- u64 mask, dmaaddr = 0, size = 0, offset = 0;
- int ret, msb;
+ u64 end, mask, dmaaddr = 0, size = 0, offset = 0;
+ int ret;
/*
* If @dev is expected to be DMA-capable then the bus code that created
@@ -1085,19 +1085,13 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
}
if (!ret) {
- msb = fls64(dmaaddr + size - 1);
/*
- * Round-up to the power-of-two mask or set
- * the mask to the whole 64-bit address space
- * in case the DMA region covers the full
- * memory window.
+ * Limit coherent and dma mask based on size retrieved from
+ * firmware.
*/
- mask = msb == 64 ? U64_MAX : (1ULL << msb) - 1;
- /*
- * Limit coherent and dma mask based on size
- * retrieved from firmware.
- */
- dev->bus_dma_mask = mask;
+ end = dmaaddr + size - 1;
+ mask = DMA_BIT_MASK(ilog2(end) + 1);
+ dev->bus_dma_limit = end;
dev->coherent_dma_mask = mask;
*dev->dma_mask = mask;
}
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ec6c64fce74a..4bfd1b14b390 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -910,7 +910,7 @@ static int ahci_configure_dma_masks(struct pci_dev *pdev, int using_dac)
* value, don't extend it here. This happens on STA2X11, for example.
*
* XXX: manipulating the DMA mask from platform code is completely
- * bogus, platform code should use dev->bus_dma_mask instead..
+ * bogus, platform code should use dev->bus_dma_limit instead..
*/
if (pdev->dma_mask && pdev->dma_mask < DMA_BIT_MASK(32))
return 0;
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 041066f3ec99..0cc702a70a96 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -421,8 +421,7 @@ static dma_addr_t iommu_dma_alloc_iova(struct iommu_domain *domain,
if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
iova_len = roundup_pow_of_two(iova_len);
- if (dev->bus_dma_mask)
- dma_limit &= dev->bus_dma_mask;
+ dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
if (domain->geometry.force_aperture)
dma_limit = min(dma_limit, domain->geometry.aperture_end);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index da8158392010..e9127db7b067 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -93,7 +93,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
bool coherent;
unsigned long offset;
const struct iommu_ops *iommu;
- u64 mask;
+ u64 mask, end;
ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
if (ret < 0) {
@@ -148,12 +148,13 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
* Limit coherent and dma mask based on size and default mask
* set by the driver.
*/
- mask = DMA_BIT_MASK(ilog2(dma_addr + size - 1) + 1);
+ end = dma_addr + size - 1;
+ mask = DMA_BIT_MASK(ilog2(end) + 1);
dev->coherent_dma_mask &= mask;
*dev->dma_mask &= mask;
- /* ...but only set bus mask if we found valid dma-ranges earlier */
+ /* ...but only set bus limit if we found valid dma-ranges earlier */
if (!ret)
- dev->bus_dma_mask = mask;
+ dev->bus_dma_limit = end;
coherent = of_dma_is_coherent(np);
dev_dbg(dev, "device is%sdma coherent\n",
diff --git a/include/linux/device.h b/include/linux/device.h
index 99af366db50d..dada6b4bd7e0 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1214,8 +1214,8 @@ struct dev_links_info {
* @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
* hardware supports 64-bit addresses for consistent allocations
* such descriptors.
- * @bus_dma_mask: Mask of an upstream bridge or bus which imposes a smaller DMA
- * limit than the device itself supports.
+ * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
+ * DMA limit than the device itself supports.
* @dma_pfn_offset: offset of DMA memory range relatively of RAM
* @dma_parms: A low level driver may set these to teach IOMMU code about
* segment limitations.
@@ -1301,7 +1301,7 @@ struct device {
not all hardware supports
64 bit addresses for consistent
allocations such descriptors. */
- u64 bus_dma_mask; /* upstream dma_mask constraint */
+ u64 bus_dma_limit; /* upstream dma constraint */
unsigned long dma_pfn_offset;
struct device_dma_parameters *dma_parms;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index c5c5b5ff2371..aa031cb213c3 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -62,7 +62,7 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
min(addr, end) < phys_to_dma(dev, PFN_PHYS(min_low_pfn)))
return false;
- return end <= min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
+ return end <= min_not_zero(*dev->dma_mask, dev->bus_dma_limit);
}
u64 dma_direct_get_required_mask(struct device *dev);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index a4930310d0c7..330ad58fbf4d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -694,7 +694,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
*/
static inline bool dma_addressing_limited(struct device *dev)
{
- return min_not_zero(dma_get_mask(dev), dev->bus_dma_mask) <
+ return min_not_zero(dma_get_mask(dev), dev->bus_dma_limit) <
dma_get_required_mask(dev);
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 84cf8be65078..998d48ddfb07 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -27,10 +27,10 @@ static void report_addr(struct device *dev, dma_addr_t dma_addr, size_t size)
{
if (!dev->dma_mask) {
dev_err_once(dev, "DMA map on device without dma_mask\n");
- } else if (*dev->dma_mask >= DMA_BIT_MASK(32) || dev->bus_dma_mask) {
+ } else if (*dev->dma_mask >= DMA_BIT_MASK(32) || dev->bus_dma_limit) {
dev_err_once(dev,
- "overflow %pad+%zu of DMA mask %llx bus mask %llx\n",
- &dma_addr, size, *dev->dma_mask, dev->bus_dma_mask);
+ "overflow %pad+%zu of DMA mask %llx bus limit %llx\n",
+ &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
}
WARN_ON_ONCE(1);
}
@@ -57,15 +57,14 @@ u64 dma_direct_get_required_mask(struct device *dev)
}
static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
- u64 *phys_mask)
+ u64 *phys_limit)
{
- if (dev->bus_dma_mask && dev->bus_dma_mask < dma_mask)
- dma_mask = dev->bus_dma_mask;
+ u64 dma_limit = min_not_zero(dma_mask, dev->bus_dma_limit);
if (force_dma_unencrypted(dev))
- *phys_mask = __dma_to_phys(dev, dma_mask);
+ *phys_limit = __dma_to_phys(dev, dma_limit);
else
- *phys_mask = dma_to_phys(dev, dma_mask);
+ *phys_limit = dma_to_phys(dev, dma_limit);
/*
* Optimistically try the zone that the physical address mask falls
@@ -75,9 +74,9 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
* Note that GFP_DMA32 and GFP_DMA are no ops without the corresponding
* zones.
*/
- if (*phys_mask <= DMA_BIT_MASK(zone_dma_bits))
+ if (*phys_limit <= DMA_BIT_MASK(zone_dma_bits))
return GFP_DMA;
- if (*phys_mask <= DMA_BIT_MASK(32))
+ if (*phys_limit <= DMA_BIT_MASK(32))
return GFP_DMA32;
return 0;
}
@@ -85,7 +84,7 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
{
return phys_to_dma_direct(dev, phys) + size - 1 <=
- min_not_zero(dev->coherent_dma_mask, dev->bus_dma_mask);
+ min_not_zero(dev->coherent_dma_mask, dev->bus_dma_limit);
}
struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
@@ -94,7 +93,7 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
size_t alloc_size = PAGE_ALIGN(size);
int node = dev_to_node(dev);
struct page *page = NULL;
- u64 phys_mask;
+ u64 phys_limit;
if (attrs & DMA_ATTR_NO_WARN)
gfp |= __GFP_NOWARN;
@@ -102,7 +101,7 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
/* we always manually zero the memory once we are done: */
gfp &= ~__GFP_ZERO;
gfp |= __dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
- &phys_mask);
+ &phys_limit);
page = dma_alloc_contiguous(dev, alloc_size, gfp);
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
dma_free_contiguous(dev, page, alloc_size);
@@ -116,7 +115,7 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
page = NULL;
if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
- phys_mask < DMA_BIT_MASK(64) &&
+ phys_limit < DMA_BIT_MASK(64) &&
!(gfp & (GFP_DMA32 | GFP_DMA))) {
gfp |= GFP_DMA32;
goto again;
--
2.24.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 9:26 [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit Nicolas Saenz Julienne
@ 2019-11-21 15:24 ` Christoph Hellwig
2019-11-21 15:26 ` Nicolas Saenz Julienne
2019-11-21 15:26 ` Christoph Hellwig
2019-11-21 17:07 ` Robin Murphy
2019-11-23 16:51 ` Nathan Chancellor
2 siblings, 2 replies; 15+ messages in thread
From: Christoph Hellwig @ 2019-11-21 15:24 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-pci,
linux-kernel, linux-ide, Paul Mackerras, Hanjun Guo,
Frank Rowand, Christoph Hellwig, H. Peter Anvin, Paul Burton,
Michael Ellerman, x86, linux-acpi, Ingo Molnar, James Hogan,
Len Brown, devicetree, Rob Herring, Borislav Petkov,
Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, linuxppc-dev, Rafael J. Wysocki,
linux-mips, Ralf Baechle, iommu, Sudeep Holla, Robin Murphy
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a limit. This quirk is already used by some architectures although
> still rare.
>
> With the introduction of the Raspberry Pi 4 we've found a new contender
> for the use of bus DMA limits, as its PCIe bus can only address the
> lower 3GB of memory (of a total of 4GB). This is impossible to represent
> with a mask. To make things worse the device-tree code rounds non power
> of two bus DMA limits to the next power of two, which is unacceptable in
> this case.
>
> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> over the tree and treat it as such. Note that dev->bus_dma_limit should
> contain the higher accesible DMA address.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
I've tentatively added this patch to the dma-mapping tree based on
Robins principal approval of the last version. That way tomorrows
linux-next run should still pick it up.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 15:24 ` Christoph Hellwig
@ 2019-11-21 15:26 ` Nicolas Saenz Julienne
2019-11-21 15:26 ` Christoph Hellwig
1 sibling, 0 replies; 15+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-21 15:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-mips,
linux-ide, Paul Mackerras, H. Peter Anvin, Frank Rowand,
Paul Burton, Michael Ellerman, x86, linux-acpi, Ingo Molnar,
linux-pci, James Hogan, Len Brown, devicetree, Rob Herring,
Borislav Petkov, Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, Rafael J. Wysocki, Robin Murphy,
Hanjun Guo, linux-kernel, Ralf Baechle, iommu, Sudeep Holla,
linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 1344 bytes --]
On Thu, 2019-11-21 at 16:24 +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> > Using a mask to represent bus DMA constraints has a set of limitations.
> > The biggest one being it can only hold a power of two (minus one). The
> > DMA mapping code is already aware of this and treats dev->bus_dma_mask
> > as a limit. This quirk is already used by some architectures although
> > still rare.
> >
> > With the introduction of the Raspberry Pi 4 we've found a new contender
> > for the use of bus DMA limits, as its PCIe bus can only address the
> > lower 3GB of memory (of a total of 4GB). This is impossible to represent
> > with a mask. To make things worse the device-tree code rounds non power
> > of two bus DMA limits to the next power of two, which is unacceptable in
> > this case.
> >
> > In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> > over the tree and treat it as such. Note that dev->bus_dma_limit should
> > contain the higher accesible DMA address.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> I've tentatively added this patch to the dma-mapping tree based on
> Robins principal approval of the last version. That way tomorrows
> linux-next run should still pick it up.
Thanks!
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 15:24 ` Christoph Hellwig
2019-11-21 15:26 ` Nicolas Saenz Julienne
@ 2019-11-21 15:26 ` Christoph Hellwig
2019-11-21 15:55 ` Robin Murphy
1 sibling, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2019-11-21 15:26 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-pci,
linux-kernel, linux-ide, Paul Mackerras, Hanjun Guo,
Frank Rowand, Christoph Hellwig, H. Peter Anvin, Paul Burton,
Michael Ellerman, x86, linux-acpi, Ingo Molnar, James Hogan,
Len Brown, devicetree, Rob Herring, Borislav Petkov,
Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, linuxppc-dev, Rafael J. Wysocki,
linux-mips, Ralf Baechle, iommu, Sudeep Holla, Robin Murphy
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> > Using a mask to represent bus DMA constraints has a set of limitations.
> > The biggest one being it can only hold a power of two (minus one). The
> > DMA mapping code is already aware of this and treats dev->bus_dma_mask
> > as a limit. This quirk is already used by some architectures although
> > still rare.
> >
> > With the introduction of the Raspberry Pi 4 we've found a new contender
> > for the use of bus DMA limits, as its PCIe bus can only address the
> > lower 3GB of memory (of a total of 4GB). This is impossible to represent
> > with a mask. To make things worse the device-tree code rounds non power
> > of two bus DMA limits to the next power of two, which is unacceptable in
> > this case.
> >
> > In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> > over the tree and treat it as such. Note that dev->bus_dma_limit should
> > contain the higher accesible DMA address.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> I've tentatively added this patch to the dma-mapping tree based on
> Robins principal approval of the last version. That way tomorrows
> linux-next run should still pick it up.
Actually. This doesn't apply because the dma-mapping tree doesn't
have you zone_dma_bits change. I guess we'll need to wait for the
next merge window, or maybe post rc1 if this happens to fix the
powerpc problem that Christian reported.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 15:26 ` Christoph Hellwig
@ 2019-11-21 15:55 ` Robin Murphy
2019-11-21 16:02 ` Christoph Hellwig
0 siblings, 1 reply; 15+ messages in thread
From: Robin Murphy @ 2019-11-21 15:55 UTC (permalink / raw)
To: Christoph Hellwig, Nicolas Saenz Julienne
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-pci,
linux-kernel, linux-ide, Paul Mackerras, H. Peter Anvin,
Frank Rowand, Paul Burton, Michael Ellerman, x86, linux-acpi,
Ingo Molnar, James Hogan, Len Brown, devicetree, Rob Herring,
Borislav Petkov, Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, Rafael J. Wysocki, Hanjun Guo,
linux-mips, Ralf Baechle, iommu, Sudeep Holla, linuxppc-dev
On 21/11/2019 3:26 pm, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
>> On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
>>> Using a mask to represent bus DMA constraints has a set of limitations.
>>> The biggest one being it can only hold a power of two (minus one). The
>>> DMA mapping code is already aware of this and treats dev->bus_dma_mask
>>> as a limit. This quirk is already used by some architectures although
>>> still rare.
>>>
>>> With the introduction of the Raspberry Pi 4 we've found a new contender
>>> for the use of bus DMA limits, as its PCIe bus can only address the
>>> lower 3GB of memory (of a total of 4GB). This is impossible to represent
>>> with a mask. To make things worse the device-tree code rounds non power
>>> of two bus DMA limits to the next power of two, which is unacceptable in
>>> this case.
>>>
>>> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
>>> over the tree and treat it as such. Note that dev->bus_dma_limit should
>>> contain the higher accesible DMA address.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>>
>> I've tentatively added this patch to the dma-mapping tree based on
>> Robins principal approval of the last version. That way tomorrows
>> linux-next run should still pick it up.
>
> Actually. This doesn't apply because the dma-mapping tree doesn't
> have you zone_dma_bits change. I guess we'll need to wait for the
> next merge window, or maybe post rc1 if this happens to fix the
> powerpc problem that Christian reported.
Hmm, there's no functional dependency though, is there? AFAICS it's
essentially just a context conflict. Is it worth simply dropping (or
postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or
perhaps even cross-merging arm64/for-next/zone-dma into dma/for-next?
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 15:55 ` Robin Murphy
@ 2019-11-21 16:02 ` Christoph Hellwig
2019-11-21 16:53 ` Will Deacon
0 siblings, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2019-11-21 16:02 UTC (permalink / raw)
To: Robin Murphy
Cc: Catalin Marinas, Peter Zijlstra, Benjamin Herrenschmidt,
Dave Hansen, linux-pci, linux-kernel, linux-ide, Paul Mackerras,
Hanjun Guo, Frank Rowand, Christoph Hellwig, H. Peter Anvin,
Paul Burton, Michael Ellerman, x86, linux-acpi, Ingo Molnar,
James Hogan, Len Brown, devicetree, Will Deacon, Rob Herring,
Borislav Petkov, Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, Rafael J. Wysocki, linux-mips,
Ralf Baechle, iommu, Sudeep Holla, linuxppc-dev,
Nicolas Saenz Julienne
On Thu, Nov 21, 2019 at 03:55:39PM +0000, Robin Murphy wrote:
> Hmm, there's no functional dependency though, is there? AFAICS it's
> essentially just a context conflict. Is it worth simply dropping (or
> postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or
> perhaps even cross-merging arm64/for-next/zone-dma into dma/for-next?
I would have no problem with pulling it in. I'd kinda hate creating
the conflict, though. So if the arm64 maintainers are fine with it
I'll pull it in, especially if I get an ACK from Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 16:02 ` Christoph Hellwig
@ 2019-11-21 16:53 ` Will Deacon
2019-11-21 17:16 ` Christoph Hellwig
0 siblings, 1 reply; 15+ messages in thread
From: Will Deacon @ 2019-11-21 16:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Catalin Marinas, Peter Zijlstra, Benjamin Herrenschmidt,
Dave Hansen, linux-pci, linux-kernel, linux-ide, Paul Mackerras,
Hanjun Guo, Frank Rowand, H. Peter Anvin, Paul Burton,
Michael Ellerman, x86, linux-acpi, Ingo Molnar, James Hogan,
Len Brown, devicetree, Rob Herring, Borislav Petkov,
Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, linuxppc-dev, Rafael J. Wysocki,
linux-mips, Ralf Baechle, iommu, Sudeep Holla, Robin Murphy,
Nicolas Saenz Julienne
On Thu, Nov 21, 2019 at 05:02:17PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 03:55:39PM +0000, Robin Murphy wrote:
> > Hmm, there's no functional dependency though, is there? AFAICS it's
> > essentially just a context conflict. Is it worth simply dropping (or
> > postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or
> > perhaps even cross-merging arm64/for-next/zone-dma into dma/for-next?
>
> I would have no problem with pulling it in. I'd kinda hate creating
> the conflict, though. So if the arm64 maintainers are fine with it
> I'll pull it in, especially if I get an ACK from Robin.
Please go ahead and pull in our for-next/zone-dma branch if you need it.
We're not going to rebase it, and I suspect we won't even be queueing
anything else there at this stage in the game.
Cheers,
Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 16:53 ` Will Deacon
@ 2019-11-21 17:16 ` Christoph Hellwig
0 siblings, 0 replies; 15+ messages in thread
From: Christoph Hellwig @ 2019-11-21 17:16 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Peter Zijlstra, Benjamin Herrenschmidt,
Dave Hansen, linux-pci, linux-kernel, linux-ide, Paul Mackerras,
Hanjun Guo, Frank Rowand, Christoph Hellwig, H. Peter Anvin,
Paul Burton, Michael Ellerman, x86, linux-acpi, Ingo Molnar,
James Hogan, Len Brown, devicetree, Rob Herring, Borislav Petkov,
Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, linuxppc-dev, Rafael J. Wysocki,
linux-mips, Ralf Baechle, iommu, Sudeep Holla, Robin Murphy,
Nicolas Saenz Julienne
On Thu, Nov 21, 2019 at 04:53:48PM +0000, Will Deacon wrote:
> Please go ahead and pull in our for-next/zone-dma branch if you need it.
> We're not going to rebase it, and I suspect we won't even be queueing
> anything else there at this stage in the game.
Ok. I've pulled it in and will wait with sending the dma-mapping
pull request until the arm64 one made it to Linus.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 9:26 [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit Nicolas Saenz Julienne
2019-11-21 15:24 ` Christoph Hellwig
@ 2019-11-21 17:07 ` Robin Murphy
2019-11-21 17:17 ` Christoph Hellwig
2019-11-23 16:51 ` Nathan Chancellor
2 siblings, 1 reply; 15+ messages in thread
From: Robin Murphy @ 2019-11-21 17:07 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Dave Hansen, Andy Lutomirski,
Peter Zijlstra, Bjorn Helgaas, Lorenzo Pieralisi, Hanjun Guo,
Sudeep Holla, Jens Axboe, Joerg Roedel, Rob Herring,
Frank Rowand, Christoph Hellwig, Marek Szyprowski
Cc: Benjamin Herrenschmidt, linux-kernel, linux-ide, Paul Mackerras,
H. Peter Anvin, Paul Burton, Michael Ellerman, x86, linux-acpi,
Ingo Molnar, linux-pci, James Hogan, Len Brown, devicetree,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Rafael J. Wysocki, linux-mips, Ralf Baechle, iommu, linuxppc-dev
On 21/11/2019 9:26 am, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a limit. This quirk is already used by some architectures although
> still rare.
>
> With the introduction of the Raspberry Pi 4 we've found a new contender
> for the use of bus DMA limits, as its PCIe bus can only address the
> lower 3GB of memory (of a total of 4GB). This is impossible to represent
> with a mask. To make things worse the device-tree code rounds non power
> of two bus DMA limits to the next power of two, which is unacceptable in
> this case.
>
> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> over the tree and treat it as such. Note that dev->bus_dma_limit should
> contain the higher accesible DMA address.
^^ super-nit only because I can't not see my editor currently
highlighting the typo: "accessible"
Regardless of that though,
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> ---
>
> Changes since v1:
> - rework ACPI code to avoid divergence with OF's
>
> arch/mips/pci/fixup-sb1250.c | 16 ++++++++--------
> arch/powerpc/sysdev/fsl_pci.c | 6 +++---
> arch/x86/kernel/pci-dma.c | 2 +-
> arch/x86/mm/mem_encrypt.c | 2 +-
> arch/x86/pci/sta2x11-fixup.c | 2 +-
> drivers/acpi/arm64/iort.c | 20 +++++++-------------
> drivers/ata/ahci.c | 2 +-
> drivers/iommu/dma-iommu.c | 3 +--
> drivers/of/device.c | 9 +++++----
> include/linux/device.h | 6 +++---
> include/linux/dma-direct.h | 2 +-
> include/linux/dma-mapping.h | 2 +-
> kernel/dma/direct.c | 27 +++++++++++++--------------
> 13 files changed, 46 insertions(+), 53 deletions(-)
>
> diff --git a/arch/mips/pci/fixup-sb1250.c b/arch/mips/pci/fixup-sb1250.c
> index 8a41b359cf90..40efc990cdce 100644
> --- a/arch/mips/pci/fixup-sb1250.c
> +++ b/arch/mips/pci/fixup-sb1250.c
> @@ -21,22 +21,22 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_PCI,
>
> /*
> * The BCM1250, etc. PCI host bridge does not support DAC on its 32-bit
> - * bus, so we set the bus's DMA mask accordingly. However the HT link
> + * bus, so we set the bus's DMA limit accordingly. However the HT link
> * down the artificial PCI-HT bridge supports 40-bit addressing and the
> * SP1011 HT-PCI bridge downstream supports both DAC and a 64-bit bus
> * width, so we record the PCI-HT bridge's secondary and subordinate bus
> - * numbers and do not set the mask for devices present in the inclusive
> + * numbers and do not set the limit for devices present in the inclusive
> * range of those.
> */
> -struct sb1250_bus_dma_mask_exclude {
> +struct sb1250_bus_dma_limit_exclude {
> bool set;
> unsigned char start;
> unsigned char end;
> };
>
> -static int sb1250_bus_dma_mask(struct pci_dev *dev, void *data)
> +static int sb1250_bus_dma_limit(struct pci_dev *dev, void *data)
> {
> - struct sb1250_bus_dma_mask_exclude *exclude = data;
> + struct sb1250_bus_dma_limit_exclude *exclude = data;
> bool exclude_this;
> bool ht_bridge;
>
> @@ -55,7 +55,7 @@ static int sb1250_bus_dma_mask(struct pci_dev *dev, void *data)
> exclude->start, exclude->end);
> } else {
> dev_dbg(&dev->dev, "disabling DAC for device");
> - dev->dev.bus_dma_mask = DMA_BIT_MASK(32);
> + dev->dev.bus_dma_limit = DMA_BIT_MASK(32);
> }
>
> return 0;
> @@ -63,9 +63,9 @@ static int sb1250_bus_dma_mask(struct pci_dev *dev, void *data)
>
> static void quirk_sb1250_pci_dac(struct pci_dev *dev)
> {
> - struct sb1250_bus_dma_mask_exclude exclude = { .set = false };
> + struct sb1250_bus_dma_limit_exclude exclude = { .set = false };
>
> - pci_walk_bus(dev->bus, sb1250_bus_dma_mask, &exclude);
> + pci_walk_bus(dev->bus, sb1250_bus_dma_limit, &exclude);
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_PCI,
> quirk_sb1250_pci_dac);
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index ff0e2b156cb5..617a443d673d 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -115,8 +115,8 @@ static void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
> {
> struct pci_controller *hose = pci_bus_to_host(pdev->bus);
>
> - pdev->dev.bus_dma_mask =
> - hose->dma_window_base_cur + hose->dma_window_size;
> + pdev->dev.bus_dma_limit =
> + hose->dma_window_base_cur + hose->dma_window_size - 1;
> }
>
> static void setup_swiotlb_ops(struct pci_controller *hose)
> @@ -135,7 +135,7 @@ static void fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
> * mapping that allows addressing any RAM address from across PCI.
> */
> if (dev_is_pci(dev) && dma_mask >= pci64_dma_offset * 2 - 1) {
> - dev->bus_dma_mask = 0;
> + dev->bus_dma_limit = 0;
> dev->archdata.dma_offset = pci64_dma_offset;
> }
> }
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 57de2ebff7e2..5dcedad21dff 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -140,7 +140,7 @@ rootfs_initcall(pci_iommu_init);
>
> static int via_no_dac_cb(struct pci_dev *pdev, void *data)
> {
> - pdev->dev.bus_dma_mask = DMA_BIT_MASK(32);
> + pdev->dev.bus_dma_limit = DMA_BIT_MASK(32);
> return 0;
> }
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 9268c12458c8..a03614bd3e1a 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -367,7 +367,7 @@ bool force_dma_unencrypted(struct device *dev)
> if (sme_active()) {
> u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
> u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
> - dev->bus_dma_mask);
> + dev->bus_dma_limit);
>
> if (dma_dev_mask <= dma_enc_mask)
> return true;
> diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
> index 4a631264b809..c313d784efab 100644
> --- a/arch/x86/pci/sta2x11-fixup.c
> +++ b/arch/x86/pci/sta2x11-fixup.c
> @@ -143,7 +143,7 @@ static void sta2x11_map_ep(struct pci_dev *pdev)
>
> dev->dma_pfn_offset = PFN_DOWN(-amba_base);
>
> - dev->bus_dma_mask = max_amba_addr;
> + dev->bus_dma_limit = max_amba_addr;
> pci_set_consistent_dma_mask(pdev, max_amba_addr);
> pci_set_dma_mask(pdev, max_amba_addr);
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 5a7551d060f2..33f71983e001 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1057,8 +1057,8 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
> */
> void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
> {
> - u64 mask, dmaaddr = 0, size = 0, offset = 0;
> - int ret, msb;
> + u64 end, mask, dmaaddr = 0, size = 0, offset = 0;
> + int ret;
>
> /*
> * If @dev is expected to be DMA-capable then the bus code that created
> @@ -1085,19 +1085,13 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
> }
>
> if (!ret) {
> - msb = fls64(dmaaddr + size - 1);
> /*
> - * Round-up to the power-of-two mask or set
> - * the mask to the whole 64-bit address space
> - * in case the DMA region covers the full
> - * memory window.
> + * Limit coherent and dma mask based on size retrieved from
> + * firmware.
> */
> - mask = msb == 64 ? U64_MAX : (1ULL << msb) - 1;
> - /*
> - * Limit coherent and dma mask based on size
> - * retrieved from firmware.
> - */
> - dev->bus_dma_mask = mask;
> + end = dmaaddr + size - 1;
> + mask = DMA_BIT_MASK(ilog2(end) + 1);
> + dev->bus_dma_limit = end;
> dev->coherent_dma_mask = mask;
> *dev->dma_mask = mask;
> }
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ec6c64fce74a..4bfd1b14b390 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -910,7 +910,7 @@ static int ahci_configure_dma_masks(struct pci_dev *pdev, int using_dac)
> * value, don't extend it here. This happens on STA2X11, for example.
> *
> * XXX: manipulating the DMA mask from platform code is completely
> - * bogus, platform code should use dev->bus_dma_mask instead..
> + * bogus, platform code should use dev->bus_dma_limit instead..
> */
> if (pdev->dma_mask && pdev->dma_mask < DMA_BIT_MASK(32))
> return 0;
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 041066f3ec99..0cc702a70a96 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -421,8 +421,7 @@ static dma_addr_t iommu_dma_alloc_iova(struct iommu_domain *domain,
> if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
> iova_len = roundup_pow_of_two(iova_len);
>
> - if (dev->bus_dma_mask)
> - dma_limit &= dev->bus_dma_mask;
> + dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
>
> if (domain->geometry.force_aperture)
> dma_limit = min(dma_limit, domain->geometry.aperture_end);
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index da8158392010..e9127db7b067 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -93,7 +93,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
> bool coherent;
> unsigned long offset;
> const struct iommu_ops *iommu;
> - u64 mask;
> + u64 mask, end;
>
> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> if (ret < 0) {
> @@ -148,12 +148,13 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
> * Limit coherent and dma mask based on size and default mask
> * set by the driver.
> */
> - mask = DMA_BIT_MASK(ilog2(dma_addr + size - 1) + 1);
> + end = dma_addr + size - 1;
> + mask = DMA_BIT_MASK(ilog2(end) + 1);
> dev->coherent_dma_mask &= mask;
> *dev->dma_mask &= mask;
> - /* ...but only set bus mask if we found valid dma-ranges earlier */
> + /* ...but only set bus limit if we found valid dma-ranges earlier */
> if (!ret)
> - dev->bus_dma_mask = mask;
> + dev->bus_dma_limit = end;
>
> coherent = of_dma_is_coherent(np);
> dev_dbg(dev, "device is%sdma coherent\n",
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 99af366db50d..dada6b4bd7e0 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -1214,8 +1214,8 @@ struct dev_links_info {
> * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
> * hardware supports 64-bit addresses for consistent allocations
> * such descriptors.
> - * @bus_dma_mask: Mask of an upstream bridge or bus which imposes a smaller DMA
> - * limit than the device itself supports.
> + * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> + * DMA limit than the device itself supports.
> * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> * @dma_parms: A low level driver may set these to teach IOMMU code about
> * segment limitations.
> @@ -1301,7 +1301,7 @@ struct device {
> not all hardware supports
> 64 bit addresses for consistent
> allocations such descriptors. */
> - u64 bus_dma_mask; /* upstream dma_mask constraint */
> + u64 bus_dma_limit; /* upstream dma constraint */
> unsigned long dma_pfn_offset;
>
> struct device_dma_parameters *dma_parms;
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index c5c5b5ff2371..aa031cb213c3 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -62,7 +62,7 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
> min(addr, end) < phys_to_dma(dev, PFN_PHYS(min_low_pfn)))
> return false;
>
> - return end <= min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
> + return end <= min_not_zero(*dev->dma_mask, dev->bus_dma_limit);
> }
>
> u64 dma_direct_get_required_mask(struct device *dev);
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index a4930310d0c7..330ad58fbf4d 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -694,7 +694,7 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
> */
> static inline bool dma_addressing_limited(struct device *dev)
> {
> - return min_not_zero(dma_get_mask(dev), dev->bus_dma_mask) <
> + return min_not_zero(dma_get_mask(dev), dev->bus_dma_limit) <
> dma_get_required_mask(dev);
> }
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 84cf8be65078..998d48ddfb07 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -27,10 +27,10 @@ static void report_addr(struct device *dev, dma_addr_t dma_addr, size_t size)
> {
> if (!dev->dma_mask) {
> dev_err_once(dev, "DMA map on device without dma_mask\n");
> - } else if (*dev->dma_mask >= DMA_BIT_MASK(32) || dev->bus_dma_mask) {
> + } else if (*dev->dma_mask >= DMA_BIT_MASK(32) || dev->bus_dma_limit) {
> dev_err_once(dev,
> - "overflow %pad+%zu of DMA mask %llx bus mask %llx\n",
> - &dma_addr, size, *dev->dma_mask, dev->bus_dma_mask);
> + "overflow %pad+%zu of DMA mask %llx bus limit %llx\n",
> + &dma_addr, size, *dev->dma_mask, dev->bus_dma_limit);
> }
> WARN_ON_ONCE(1);
> }
> @@ -57,15 +57,14 @@ u64 dma_direct_get_required_mask(struct device *dev)
> }
>
> static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
> - u64 *phys_mask)
> + u64 *phys_limit)
> {
> - if (dev->bus_dma_mask && dev->bus_dma_mask < dma_mask)
> - dma_mask = dev->bus_dma_mask;
> + u64 dma_limit = min_not_zero(dma_mask, dev->bus_dma_limit);
>
> if (force_dma_unencrypted(dev))
> - *phys_mask = __dma_to_phys(dev, dma_mask);
> + *phys_limit = __dma_to_phys(dev, dma_limit);
> else
> - *phys_mask = dma_to_phys(dev, dma_mask);
> + *phys_limit = dma_to_phys(dev, dma_limit);
>
> /*
> * Optimistically try the zone that the physical address mask falls
> @@ -75,9 +74,9 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
> * Note that GFP_DMA32 and GFP_DMA are no ops without the corresponding
> * zones.
> */
> - if (*phys_mask <= DMA_BIT_MASK(zone_dma_bits))
> + if (*phys_limit <= DMA_BIT_MASK(zone_dma_bits))
> return GFP_DMA;
> - if (*phys_mask <= DMA_BIT_MASK(32))
> + if (*phys_limit <= DMA_BIT_MASK(32))
> return GFP_DMA32;
> return 0;
> }
> @@ -85,7 +84,7 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
> static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
> {
> return phys_to_dma_direct(dev, phys) + size - 1 <=
> - min_not_zero(dev->coherent_dma_mask, dev->bus_dma_mask);
> + min_not_zero(dev->coherent_dma_mask, dev->bus_dma_limit);
> }
>
> struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> @@ -94,7 +93,7 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> size_t alloc_size = PAGE_ALIGN(size);
> int node = dev_to_node(dev);
> struct page *page = NULL;
> - u64 phys_mask;
> + u64 phys_limit;
>
> if (attrs & DMA_ATTR_NO_WARN)
> gfp |= __GFP_NOWARN;
> @@ -102,7 +101,7 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> /* we always manually zero the memory once we are done: */
> gfp &= ~__GFP_ZERO;
> gfp |= __dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
> - &phys_mask);
> + &phys_limit);
> page = dma_alloc_contiguous(dev, alloc_size, gfp);
> if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> dma_free_contiguous(dev, page, alloc_size);
> @@ -116,7 +115,7 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> page = NULL;
>
> if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
> - phys_mask < DMA_BIT_MASK(64) &&
> + phys_limit < DMA_BIT_MASK(64) &&
> !(gfp & (GFP_DMA32 | GFP_DMA))) {
> gfp |= GFP_DMA32;
> goto again;
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 17:07 ` Robin Murphy
@ 2019-11-21 17:17 ` Christoph Hellwig
0 siblings, 0 replies; 15+ messages in thread
From: Christoph Hellwig @ 2019-11-21 17:17 UTC (permalink / raw)
To: Robin Murphy
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-pci,
linux-kernel, linux-ide, Paul Mackerras, Hanjun Guo,
Frank Rowand, Christoph Hellwig, H. Peter Anvin, Paul Burton,
Michael Ellerman, x86, linux-acpi, Ingo Molnar, James Hogan,
Len Brown, devicetree, Rob Herring, Borislav Petkov,
Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, Rafael J. Wysocki, linux-mips,
Ralf Baechle, iommu, Sudeep Holla, linuxppc-dev,
Nicolas Saenz Julienne
On Thu, Nov 21, 2019 at 05:07:54PM +0000, Robin Murphy wrote:
> ^^ super-nit only because I can't not see my editor currently highlighting
> the typo: "accessible"
>
> Regardless of that though,
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Applied for real now with that typo fixed and on top of the pulled in
arm64 branch.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-21 9:26 [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit Nicolas Saenz Julienne
2019-11-21 15:24 ` Christoph Hellwig
2019-11-21 17:07 ` Robin Murphy
@ 2019-11-23 16:51 ` Nathan Chancellor
2019-11-25 7:44 ` Christoph Hellwig
2 siblings, 1 reply; 15+ messages in thread
From: Nathan Chancellor @ 2019-11-23 16:51 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-mips,
linux-ide, Paul Mackerras, Hanjun Guo, Frank Rowand,
Christoph Hellwig, H. Peter Anvin, Paul Burton, Michael Ellerman,
x86, linux-acpi, Ingo Molnar, linux-pci, James Hogan, Len Brown,
devicetree, Rob Herring, Borislav Petkov, Andy Lutomirski,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel, Jens Axboe,
linuxppc-dev, Rafael J. Wysocki, linux-kernel, Ralf Baechle,
iommu, Sudeep Holla, Robin Murphy
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a limit. This quirk is already used by some architectures although
> still rare.
>
> With the introduction of the Raspberry Pi 4 we've found a new contender
> for the use of bus DMA limits, as its PCIe bus can only address the
> lower 3GB of memory (of a total of 4GB). This is impossible to represent
> with a mask. To make things worse the device-tree code rounds non power
> of two bus DMA limits to the next power of two, which is unacceptable in
> this case.
>
> In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
> over the tree and treat it as such. Note that dev->bus_dma_limit should
> contain the higher accesible DMA address.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
<snip>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 041066f3ec99..0cc702a70a96 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -421,8 +421,7 @@ static dma_addr_t iommu_dma_alloc_iova(struct iommu_domain *domain,
> if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
> iova_len = roundup_pow_of_two(iova_len);
>
> - if (dev->bus_dma_mask)
> - dma_limit &= dev->bus_dma_mask;
> + dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
>
> if (domain->geometry.force_aperture)
> dma_limit = min(dma_limit, domain->geometry.aperture_end);
Just as an FYI, this introduces a warning on arm32 allyesconfig for me:
In file included from ../include/linux/list.h:9,
from ../include/linux/kobject.h:19,
from ../include/linux/of.h:17,
from ../include/linux/irqdomain.h:35,
from ../include/linux/acpi.h:13,
from ../include/linux/acpi_iort.h:10,
from ../drivers/iommu/dma-iommu.c:11:
../drivers/iommu/dma-iommu.c: In function 'iommu_dma_alloc_iova':
../include/linux/kernel.h:851:29: warning: comparison of distinct pointer types lacks a cast
851 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~
../include/linux/kernel.h:865:4: note: in expansion of macro '__typecheck'
865 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~
../include/linux/kernel.h:875:24: note: in expansion of macro '__safe_cmp'
875 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~
../include/linux/kernel.h:884:19: note: in expansion of macro '__careful_cmp'
884 | #define min(x, y) __careful_cmp(x, y, <)
| ^~~~~~~~~~~~~
../include/linux/kernel.h:917:39: note: in expansion of macro 'min'
917 | __x == 0 ? __y : ((__y == 0) ? __x : min(__x, __y)); })
| ^~~
../drivers/iommu/dma-iommu.c:424:14: note: in expansion of macro 'min_not_zero'
424 | dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
| ^~~~~~~~~~~~
Cheers,
Nathan
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-23 16:51 ` Nathan Chancellor
@ 2019-11-25 7:44 ` Christoph Hellwig
2019-11-25 16:33 ` Robin Murphy
0 siblings, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2019-11-25 7:44 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-mips,
linux-ide, Paul Mackerras, Hanjun Guo, Frank Rowand,
Christoph Hellwig, H. Peter Anvin, Paul Burton, Michael Ellerman,
x86, linux-acpi, Ingo Molnar, linux-pci, James Hogan, Len Brown,
devicetree, Rob Herring, Borislav Petkov, Andy Lutomirski,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel, Jens Axboe,
linuxppc-dev, Rafael J. Wysocki, linux-kernel, Ralf Baechle,
iommu, Sudeep Holla, Robin Murphy, Nicolas Saenz Julienne
On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
> Just as an FYI, this introduces a warning on arm32 allyesconfig for me:
I think the dma_limit argument to iommu_dma_alloc_iova should be a u64
and/or we need to use min_t and open code the zero exception.
Robin, Nicolas - any opinions?
Also I wonder how this file gets compiled on arm32 given that arm32
has its own set of iommu dma ops..
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-25 7:44 ` Christoph Hellwig
@ 2019-11-25 16:33 ` Robin Murphy
2019-11-26 18:51 ` Nicolas Saenz Julienne
0 siblings, 1 reply; 15+ messages in thread
From: Robin Murphy @ 2019-11-25 16:33 UTC (permalink / raw)
To: Christoph Hellwig, Nathan Chancellor
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-mips,
linux-ide, Paul Mackerras, H. Peter Anvin, Frank Rowand,
Paul Burton, Michael Ellerman, x86, linux-acpi, Ingo Molnar,
linux-pci, James Hogan, Len Brown, devicetree, Rob Herring,
Borislav Petkov, Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, Rafael J. Wysocki, Hanjun Guo,
linux-kernel, Ralf Baechle, iommu, Sudeep Holla, linuxppc-dev,
Nicolas Saenz Julienne
On 25/11/2019 7:44 am, Christoph Hellwig wrote:
> On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
>> Just as an FYI, this introduces a warning on arm32 allyesconfig for me:
>
> I think the dma_limit argument to iommu_dma_alloc_iova should be a u64
> and/or we need to use min_t and open code the zero exception.
>
> Robin, Nicolas - any opinions?
Yeah, given that it's always held a mask I'm not entirely sure why it
was ever a dma_addr_t rather than a u64. Unless anyone else is desperate
to do it I'll get a cleanup patch ready for rc1.
> Also I wonder how this file gets compiled on arm32 given that arm32
> has its own set of iommu dma ops..
As long as the dependencies for CONFIG_IOMMU_DMA are met it can be built
even when it's not actually used. That said, I might have expected that
arm allyesconfig ends up with CONFIG_ARCH_DMA_ADDR_T_64BIT=y anyway; I
guess it must pick some of CONFIG_ARM_LPAE's negative dependencies.
(/me doesn't feel like jumping down the all*config rabbit hole today)
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-25 16:33 ` Robin Murphy
@ 2019-11-26 18:51 ` Nicolas Saenz Julienne
2019-11-26 21:45 ` Robin Murphy
0 siblings, 1 reply; 15+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-26 18:51 UTC (permalink / raw)
To: Robin Murphy, Christoph Hellwig, Nathan Chancellor
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-mips,
linux-ide, Paul Mackerras, H. Peter Anvin, Frank Rowand,
Paul Burton, Michael Ellerman, x86, linux-acpi, Ingo Molnar,
linux-pci, James Hogan, Len Brown, devicetree, Rob Herring,
Borislav Petkov, Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, Rafael J. Wysocki, Hanjun Guo,
linux-kernel, Ralf Baechle, iommu, Sudeep Holla, linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 807 bytes --]
On Mon, 2019-11-25 at 16:33 +0000, Robin Murphy wrote:
> On 25/11/2019 7:44 am, Christoph Hellwig wrote:
> > On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
> > > Just as an FYI, this introduces a warning on arm32 allyesconfig for me:
> >
> > I think the dma_limit argument to iommu_dma_alloc_iova should be a u64
> > and/or we need to use min_t and open code the zero exception.
> >
> > Robin, Nicolas - any opinions?
>
> Yeah, given that it's always held a mask I'm not entirely sure why it
> was ever a dma_addr_t rather than a u64. Unless anyone else is desperate
> to do it I'll get a cleanup patch ready for rc1.
Sounds good to me too
Robin, since I started the mess, I'll be happy to do it if it helps offloading
some work from you.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
2019-11-26 18:51 ` Nicolas Saenz Julienne
@ 2019-11-26 21:45 ` Robin Murphy
0 siblings, 0 replies; 15+ messages in thread
From: Robin Murphy @ 2019-11-26 21:45 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Christoph Hellwig, Nathan Chancellor
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, linux-mips,
linux-ide, Paul Mackerras, H. Peter Anvin, Frank Rowand,
Paul Burton, Michael Ellerman, x86, linux-acpi, Ingo Molnar,
linux-pci, James Hogan, Len Brown, devicetree, Rob Herring,
Borislav Petkov, Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel, Jens Axboe, Rafael J. Wysocki, Hanjun Guo,
linux-kernel, Ralf Baechle, iommu, Sudeep Holla, linuxppc-dev
On 2019-11-26 6:51 pm, Nicolas Saenz Julienne wrote:
> On Mon, 2019-11-25 at 16:33 +0000, Robin Murphy wrote:
>> On 25/11/2019 7:44 am, Christoph Hellwig wrote:
>>> On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote:
>>>> Just as an FYI, this introduces a warning on arm32 allyesconfig for me:
>>>
>>> I think the dma_limit argument to iommu_dma_alloc_iova should be a u64
>>> and/or we need to use min_t and open code the zero exception.
>>>
>>> Robin, Nicolas - any opinions?
>>
>> Yeah, given that it's always held a mask I'm not entirely sure why it
>> was ever a dma_addr_t rather than a u64. Unless anyone else is desperate
>> to do it I'll get a cleanup patch ready for rc1.
>
> Sounds good to me too
>
> Robin, since I started the mess, I'll be happy to do it if it helps offloading
> some work from you.
No worries - your change only exposed my original weird decision ;) On
second look the patch was literally a trivial one-liner, so I've written
it up already.
Cheers,
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-11-26 21:45 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-21 9:26 [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit Nicolas Saenz Julienne
2019-11-21 15:24 ` Christoph Hellwig
2019-11-21 15:26 ` Nicolas Saenz Julienne
2019-11-21 15:26 ` Christoph Hellwig
2019-11-21 15:55 ` Robin Murphy
2019-11-21 16:02 ` Christoph Hellwig
2019-11-21 16:53 ` Will Deacon
2019-11-21 17:16 ` Christoph Hellwig
2019-11-21 17:07 ` Robin Murphy
2019-11-21 17:17 ` Christoph Hellwig
2019-11-23 16:51 ` Nathan Chancellor
2019-11-25 7:44 ` Christoph Hellwig
2019-11-25 16:33 ` Robin Murphy
2019-11-26 18:51 ` Nicolas Saenz Julienne
2019-11-26 21:45 ` Robin Murphy
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).