* [PATCH v2 0/2] x86: Get rid of custom DMA functions @ 2019-10-18 11:00 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-18 11:00 UTC (permalink / raw) To: rubini, hch, linux-kernel Cc: linux-pci, iommu, helgaas, H. Peter Anvin, Robin Murphy, Nicolas Saenz Julienne sta2x11 is the only x86 device that depends custom DMA direct functions. It turns out it can be made standard by carefully setting the device's DMA masks and offset. Originally only patch #2 was sent but I realised patch #1 is also needed, which is a good addition as it's also a prerequisite to get proper DMA support on the Raspberry Pi 4[1]. [1] https://lkml.org/lkml/2019/10/15/523 --- Changes since v1: - Small cleanups in sta2x11-fixup.x - add patch checking DMA addresses lower bounds Nicolas Saenz Julienne (2): dma-direct: check for overflows on 32 bit DMA addresses x86/PCI: sta2x11: use default DMA address translation ops arch/x86/Kconfig | 1 - arch/x86/include/asm/device.h | 3 - arch/x86/include/asm/dma-direct.h | 9 -- arch/x86/pci/sta2x11-fixup.c | 135 ++++++------------------------ include/linux/dma-direct.h | 8 ++ 5 files changed, 34 insertions(+), 122 deletions(-) delete mode 100644 arch/x86/include/asm/dma-direct.h -- 2.23.0 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 0/2] x86: Get rid of custom DMA functions @ 2019-10-18 11:00 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-18 11:00 UTC (permalink / raw) To: rubini, hch, linux-kernel Cc: helgaas, Nicolas Saenz Julienne, H. Peter Anvin, Robin Murphy, linux-pci, iommu sta2x11 is the only x86 device that depends custom DMA direct functions. It turns out it can be made standard by carefully setting the device's DMA masks and offset. Originally only patch #2 was sent but I realised patch #1 is also needed, which is a good addition as it's also a prerequisite to get proper DMA support on the Raspberry Pi 4[1]. [1] https://lkml.org/lkml/2019/10/15/523 --- Changes since v1: - Small cleanups in sta2x11-fixup.x - add patch checking DMA addresses lower bounds Nicolas Saenz Julienne (2): dma-direct: check for overflows on 32 bit DMA addresses x86/PCI: sta2x11: use default DMA address translation ops arch/x86/Kconfig | 1 - arch/x86/include/asm/device.h | 3 - arch/x86/include/asm/dma-direct.h | 9 -- arch/x86/pci/sta2x11-fixup.c | 135 ++++++------------------------ include/linux/dma-direct.h | 8 ++ 5 files changed, 34 insertions(+), 122 deletions(-) delete mode 100644 arch/x86/include/asm/dma-direct.h -- 2.23.0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses 2019-10-18 11:00 ` Nicolas Saenz Julienne @ 2019-10-18 11:00 ` Nicolas Saenz Julienne -1 siblings, 0 replies; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-18 11:00 UTC (permalink / raw) To: rubini, hch, linux-kernel, Christoph Hellwig, Marek Szyprowski, Robin Murphy Cc: iommu, helgaas, Nicolas Saenz Julienne As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is possible for a device configured with 32 bit DMA addresses and a partial DMA mapping located at the end of the address space to overflow. It happens when a higher physical address, not DMAable, is translated to it's DMA counterpart. For example the Raspberry Pi 4, configurable up to 4 GB of memory, has an interconnect capable of addressing the lower 1 GB of physical memory with a DMA offset of 0xc0000000. It transpires that, any attempt to translate physical addresses higher than the first GB will result in an overflow which dma_capable() can't detect as it only checks for addresses bigger then the maximum allowed DMA address. Fix this by verifying in dma_capable() if the DMA address range provided is at any point lower than the minimum possible DMA address on the bus. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- include/linux/dma-direct.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index adf993a3bd58..af4bb9c81ccc 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -3,6 +3,7 @@ #define _LINUX_DMA_DIRECT_H 1 #include <linux/dma-mapping.h> +#include <linux/memblock.h> /* for min_low_pfn */ #include <linux/mem_encrypt.h> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) if (!dev->dma_mask) return false; +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT + /* Check if DMA address overflowed */ + if (min(addr, addr + size - 1) < + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) + return false; +#endif + return addr + size - 1 <= min_not_zero(*dev->dma_mask, dev->bus_dma_mask); } -- 2.23.0 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses @ 2019-10-18 11:00 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-18 11:00 UTC (permalink / raw) To: rubini, hch, linux-kernel, Christoph Hellwig, Marek Szyprowski, Robin Murphy Cc: helgaas, Nicolas Saenz Julienne, iommu As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is possible for a device configured with 32 bit DMA addresses and a partial DMA mapping located at the end of the address space to overflow. It happens when a higher physical address, not DMAable, is translated to it's DMA counterpart. For example the Raspberry Pi 4, configurable up to 4 GB of memory, has an interconnect capable of addressing the lower 1 GB of physical memory with a DMA offset of 0xc0000000. It transpires that, any attempt to translate physical addresses higher than the first GB will result in an overflow which dma_capable() can't detect as it only checks for addresses bigger then the maximum allowed DMA address. Fix this by verifying in dma_capable() if the DMA address range provided is at any point lower than the minimum possible DMA address on the bus. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- include/linux/dma-direct.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index adf993a3bd58..af4bb9c81ccc 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -3,6 +3,7 @@ #define _LINUX_DMA_DIRECT_H 1 #include <linux/dma-mapping.h> +#include <linux/memblock.h> /* for min_low_pfn */ #include <linux/mem_encrypt.h> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) if (!dev->dma_mask) return false; +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT + /* Check if DMA address overflowed */ + if (min(addr, addr + size - 1) < + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) + return false; +#endif + return addr + size - 1 <= min_not_zero(*dev->dma_mask, dev->bus_dma_mask); } -- 2.23.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses 2019-10-18 11:00 ` Nicolas Saenz Julienne @ 2019-10-30 21:41 ` Christoph Hellwig -1 siblings, 0 replies; 12+ messages in thread From: Christoph Hellwig @ 2019-10-30 21:41 UTC (permalink / raw) To: Nicolas Saenz Julienne; +Cc: rubini, linux-kernel, iommu, helgaas, Robin Murphy On Fri, Oct 18, 2019 at 01:00:43PM +0200, Nicolas Saenz Julienne wrote: > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT > + /* Check if DMA address overflowed */ > + if (min(addr, addr + size - 1) < > + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) > + return false; > +#endif Would be nice to use IS_ENABLED and PFN_PHYS here, and I also think we need to use phys_to_dma to take care of the encryption bit. If you then also introduce an end variable we can make the whole thing actually look nice: static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) { dma_addr_t end = addr + size - 1; if (!dev->dma_mask) return false; if (!IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) && 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); } Otherwise this looks sensible to me. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses @ 2019-10-30 21:41 ` Christoph Hellwig 0 siblings, 0 replies; 12+ messages in thread From: Christoph Hellwig @ 2019-10-30 21:41 UTC (permalink / raw) To: Nicolas Saenz Julienne Cc: rubini, hch, linux-kernel, Marek Szyprowski, Robin Murphy, helgaas, iommu On Fri, Oct 18, 2019 at 01:00:43PM +0200, Nicolas Saenz Julienne wrote: > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT > + /* Check if DMA address overflowed */ > + if (min(addr, addr + size - 1) < > + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) > + return false; > +#endif Would be nice to use IS_ENABLED and PFN_PHYS here, and I also think we need to use phys_to_dma to take care of the encryption bit. If you then also introduce an end variable we can make the whole thing actually look nice: static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) { dma_addr_t end = addr + size - 1; if (!dev->dma_mask) return false; if (!IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) && 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); } Otherwise this looks sensible to me. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses 2019-10-30 21:41 ` Christoph Hellwig @ 2019-10-31 10:44 ` Nicolas Saenz Julienne -1 siblings, 0 replies; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-31 10:44 UTC (permalink / raw) To: Christoph Hellwig; +Cc: rubini, linux-kernel, iommu, helgaas, Robin Murphy [-- Attachment #1.1: Type: text/plain, Size: 1099 bytes --] On Wed, 2019-10-30 at 14:41 -0700, Christoph Hellwig wrote: > On Fri, Oct 18, 2019 at 01:00:43PM +0200, Nicolas Saenz Julienne wrote: > > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT > > + /* Check if DMA address overflowed */ > > + if (min(addr, addr + size - 1) < > > + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) > > + return false; > > +#endif > > Would be nice to use IS_ENABLED and PFN_PHYS here, and I also think we > need to use phys_to_dma to take care of the encryption bit. If you then > also introduce an end variable we can make the whole thing actually look > nice: > > static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t > size) > { > dma_addr_t end = addr + size - 1; > > if (!dev->dma_mask) > return false; > > if (!IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) && > 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); > } > > Otherwise this looks sensible to me. Thanks, noted. [-- 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] 12+ messages in thread
* Re: [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses @ 2019-10-31 10:44 ` Nicolas Saenz Julienne 0 siblings, 0 replies; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-31 10:44 UTC (permalink / raw) To: Christoph Hellwig Cc: rubini, linux-kernel, Marek Szyprowski, Robin Murphy, helgaas, iommu [-- Attachment #1: Type: text/plain, Size: 1099 bytes --] On Wed, 2019-10-30 at 14:41 -0700, Christoph Hellwig wrote: > On Fri, Oct 18, 2019 at 01:00:43PM +0200, Nicolas Saenz Julienne wrote: > > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT > > + /* Check if DMA address overflowed */ > > + if (min(addr, addr + size - 1) < > > + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) > > + return false; > > +#endif > > Would be nice to use IS_ENABLED and PFN_PHYS here, and I also think we > need to use phys_to_dma to take care of the encryption bit. If you then > also introduce an end variable we can make the whole thing actually look > nice: > > static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t > size) > { > dma_addr_t end = addr + size - 1; > > if (!dev->dma_mask) > return false; > > if (!IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) && > 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); > } > > Otherwise this looks sensible to me. Thanks, noted. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/2] x86/PCI: sta2x11: use default DMA address translation 2019-10-18 11:00 ` Nicolas Saenz Julienne (?) (?) @ 2019-10-18 11:00 ` Nicolas Saenz Julienne 2019-10-30 21:45 ` Christoph Hellwig -1 siblings, 1 reply; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-18 11:00 UTC (permalink / raw) To: rubini, hch, linux-kernel, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Bjorn Helgaas Cc: helgaas, Nicolas Saenz Julienne, linux-pci The devices found behind this PCIe chip have unusual DMA mapping constraints as there is an AMBA interconnect placed in between them and the different PCI endpoints. The offset between physical memory addresses and AMBA's view is provided by reading a PCI config register, which is saved and used whenever DMA mapping is needed. It turns out that this DMA setup can be represented by properly setting 'dma_pfn_offset', 'dma_bus_mask' and 'dma_mask' during the PCI device enable fixup. And ultimately allows us to get rid of this device's custom DMA functions. Aside from the code deletion and DMA setup, sta2x11_pdev_to_mapping() is moved to avoid warnings whenever CONFIG_PM is not enabled. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> --- Changed since v1: - use variable to avoid recalculating AMBA's max address - remove x86's dma-direct.h as it's not longer needed Note: This was only compile tested. Also, there was some conversation here: https://lkml.org/lkml/2019/10/17/1014, that Christoph might have missed as I misspelled his email on v1. arch/x86/Kconfig | 1 - arch/x86/include/asm/device.h | 3 - arch/x86/include/asm/dma-direct.h | 9 -- arch/x86/pci/sta2x11-fixup.c | 135 ++++++------------------------ 4 files changed, 26 insertions(+), 122 deletions(-) delete mode 100644 arch/x86/include/asm/dma-direct.h diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index abe822d52167..9c2a51e1cb59 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -708,7 +708,6 @@ config X86_SUPPORTS_MEMORY_FAILURE config STA2X11 bool "STA2X11 Companion Chip Support" depends on X86_32_NON_STANDARD && PCI - select ARCH_HAS_PHYS_TO_DMA select SWIOTLB select MFD_STA2X11 select GPIOLIB diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h index a8f6c809d9b1..5e12c63b47aa 100644 --- a/arch/x86/include/asm/device.h +++ b/arch/x86/include/asm/device.h @@ -6,9 +6,6 @@ struct dev_archdata { #if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU) void *iommu; /* hook for IOMMU specific extension */ #endif -#ifdef CONFIG_STA2X11 - bool is_sta2x11; -#endif }; #if defined(CONFIG_X86_DEV_DMA_OPS) && defined(CONFIG_PCI_DOMAINS) diff --git a/arch/x86/include/asm/dma-direct.h b/arch/x86/include/asm/dma-direct.h deleted file mode 100644 index 1a19251eaac9..000000000000 --- a/arch/x86/include/asm/dma-direct.h +++ /dev/null @@ -1,9 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef ASM_X86_DMA_DIRECT_H -#define ASM_X86_DMA_DIRECT_H 1 - -bool dma_capable(struct device *dev, dma_addr_t addr, size_t size); -dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr); -phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr); - -#endif /* ASM_X86_DMA_DIRECT_H */ diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c index 6269a175385d..4a631264b809 100644 --- a/arch/x86/pci/sta2x11-fixup.c +++ b/arch/x86/pci/sta2x11-fixup.c @@ -30,7 +30,6 @@ struct sta2x11_ahb_regs { /* saved during suspend */ }; struct sta2x11_mapping { - u32 amba_base; int is_suspended; struct sta2x11_ahb_regs regs[STA2X11_NR_FUNCS]; }; @@ -92,18 +91,6 @@ static int sta2x11_pdev_to_ep(struct pci_dev *pdev) return pdev->bus->number - instance->bus0; } -static struct sta2x11_mapping *sta2x11_pdev_to_mapping(struct pci_dev *pdev) -{ - struct sta2x11_instance *instance; - int ep; - - instance = sta2x11_pdev_to_instance(pdev); - if (!instance) - return NULL; - ep = sta2x11_pdev_to_ep(pdev); - return instance->map + ep; -} - /* This is exported, as some devices need to access the MFD registers */ struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev) { @@ -111,39 +98,6 @@ struct sta2x11_instance *sta2x11_get_instance(struct pci_dev *pdev) } EXPORT_SYMBOL(sta2x11_get_instance); - -/** - * p2a - Translate physical address to STA2x11 AMBA address, - * used for DMA transfers to STA2x11 - * @p: Physical address - * @pdev: PCI device (must be hosted within the connext) - */ -static dma_addr_t p2a(dma_addr_t p, struct pci_dev *pdev) -{ - struct sta2x11_mapping *map; - dma_addr_t a; - - map = sta2x11_pdev_to_mapping(pdev); - a = p + map->amba_base; - return a; -} - -/** - * a2p - Translate STA2x11 AMBA address to physical address - * used for DMA transfers from STA2x11 - * @a: STA2x11 AMBA address - * @pdev: PCI device (must be hosted within the connext) - */ -static dma_addr_t a2p(dma_addr_t a, struct pci_dev *pdev) -{ - struct sta2x11_mapping *map; - dma_addr_t p; - - map = sta2x11_pdev_to_mapping(pdev); - p = a - map->amba_base; - return p; -} - /* At setup time, we use our own ops if the device is a ConneXt one */ static void sta2x11_setup_pdev(struct pci_dev *pdev) { @@ -151,70 +105,12 @@ static void sta2x11_setup_pdev(struct pci_dev *pdev) if (!instance) /* either a sta2x11 bridge or another ST device */ return; - pci_set_consistent_dma_mask(pdev, STA2X11_AMBA_SIZE - 1); - pci_set_dma_mask(pdev, STA2X11_AMBA_SIZE - 1); - pdev->dev.archdata.is_sta2x11 = true; /* We must enable all devices as master, for audio DMA to work */ pci_set_master(pdev); } DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_setup_pdev); -/* - * The following three functions are exported (used in swiotlb: FIXME) - */ -/** - * dma_capable - Check if device can manage DMA transfers (FIXME: kill it) - * @dev: device for a PCI device - * @addr: DMA address - * @size: DMA size - */ -bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) -{ - struct sta2x11_mapping *map; - - if (!dev->archdata.is_sta2x11) { - if (!dev->dma_mask) - return false; - return addr + size - 1 <= *dev->dma_mask; - } - - map = sta2x11_pdev_to_mapping(to_pci_dev(dev)); - - if (!map || (addr < map->amba_base)) - return false; - if (addr + size >= map->amba_base + STA2X11_AMBA_SIZE) { - return false; - } - - return true; -} - -/** - * __phys_to_dma - Return the DMA AMBA address used for this STA2x11 device - * @dev: device for a PCI device - * @paddr: Physical address - */ -dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr) -{ - if (!dev->archdata.is_sta2x11) - return paddr; - return p2a(paddr, to_pci_dev(dev)); -} - -/** - * dma_to_phys - Return the physical address used for this STA2x11 DMA address - * @dev: device for a PCI device - * @daddr: STA2x11 AMBA DMA address - */ -phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr) -{ - if (!dev->archdata.is_sta2x11) - return daddr; - return a2p(daddr, to_pci_dev(dev)); -} - - /* * At boot we must set up the mappings for the pcie-to-amba bridge. * It involves device access, and the same happens at suspend/resume time @@ -234,12 +130,22 @@ phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr) /* At probe time, enable mapping for each endpoint, using the pdev */ static void sta2x11_map_ep(struct pci_dev *pdev) { - struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev); + struct sta2x11_instance *instance = sta2x11_pdev_to_instance(pdev); + struct device *dev = &pdev->dev; + u32 amba_base, max_amba_addr; int i; - if (!map) + if (!instance) return; - pci_read_config_dword(pdev, AHB_BASE(0), &map->amba_base); + + pci_read_config_dword(pdev, AHB_BASE(0), &amba_base); + max_amba_addr = amba_base + STA2X11_AMBA_SIZE - 1; + + dev->dma_pfn_offset = PFN_DOWN(-amba_base); + + dev->bus_dma_mask = max_amba_addr; + pci_set_consistent_dma_mask(pdev, max_amba_addr); + pci_set_dma_mask(pdev, max_amba_addr); /* Configure AHB mapping */ pci_write_config_dword(pdev, AHB_PEXLBASE(0), 0); @@ -253,13 +159,24 @@ static void sta2x11_map_ep(struct pci_dev *pdev) dev_info(&pdev->dev, "sta2x11: Map EP %i: AMBA address %#8x-%#8x\n", - sta2x11_pdev_to_ep(pdev), map->amba_base, - map->amba_base + STA2X11_AMBA_SIZE - 1); + sta2x11_pdev_to_ep(pdev), amba_base, max_amba_addr); } DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_STMICRO, PCI_ANY_ID, sta2x11_map_ep); #ifdef CONFIG_PM /* Some register values must be saved and restored */ +static struct sta2x11_mapping *sta2x11_pdev_to_mapping(struct pci_dev *pdev) +{ + struct sta2x11_instance *instance; + int ep; + + instance = sta2x11_pdev_to_instance(pdev); + if (!instance) + return NULL; + ep = sta2x11_pdev_to_ep(pdev); + return instance->map + ep; +} + static void suspend_mapping(struct pci_dev *pdev) { struct sta2x11_mapping *map = sta2x11_pdev_to_mapping(pdev); -- 2.23.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] x86/PCI: sta2x11: use default DMA address translation 2019-10-18 11:00 ` [PATCH v2 2/2] x86/PCI: sta2x11: use default DMA address translation Nicolas Saenz Julienne @ 2019-10-30 21:45 ` Christoph Hellwig 2019-10-31 10:43 ` Nicolas Saenz Julienne 0 siblings, 1 reply; 12+ messages in thread From: Christoph Hellwig @ 2019-10-30 21:45 UTC (permalink / raw) To: Nicolas Saenz Julienne Cc: rubini, hch, linux-kernel, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Bjorn Helgaas, helgaas, linux-pci On Fri, Oct 18, 2019 at 01:00:44PM +0200, Nicolas Saenz Julienne wrote: > The devices found behind this PCIe chip have unusual DMA mapping > constraints as there is an AMBA interconnect placed in between them and > the different PCI endpoints. The offset between physical memory > addresses and AMBA's view is provided by reading a PCI config register, > which is saved and used whenever DMA mapping is needed. > > It turns out that this DMA setup can be represented by properly setting > 'dma_pfn_offset', 'dma_bus_mask' and 'dma_mask' during the PCI device > enable fixup. And ultimately allows us to get rid of this device's > custom DMA functions. > > Aside from the code deletion and DMA setup, sta2x11_pdev_to_mapping() is > moved to avoid warnings whenever CONFIG_PM is not enabled. Looks sensible to me: Reviewed-by: Christoph Hellwig <hch@lst.de> But I can't tested it either, and kinda wonder if this code is actually still used by anyone.. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] x86/PCI: sta2x11: use default DMA address translation 2019-10-30 21:45 ` Christoph Hellwig @ 2019-10-31 10:43 ` Nicolas Saenz Julienne 2019-10-31 13:59 ` Alessandro Rubini 0 siblings, 1 reply; 12+ messages in thread From: Nicolas Saenz Julienne @ 2019-10-31 10:43 UTC (permalink / raw) To: Christoph Hellwig, rubini Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Bjorn Helgaas, helgaas, linux-pci [-- Attachment #1: Type: text/plain, Size: 1174 bytes --] On Wed, 2019-10-30 at 14:45 -0700, Christoph Hellwig wrote: > On Fri, Oct 18, 2019 at 01:00:44PM +0200, Nicolas Saenz Julienne wrote: > > The devices found behind this PCIe chip have unusual DMA mapping > > constraints as there is an AMBA interconnect placed in between them and > > the different PCI endpoints. The offset between physical memory > > addresses and AMBA's view is provided by reading a PCI config register, > > which is saved and used whenever DMA mapping is needed. > > > > It turns out that this DMA setup can be represented by properly setting > > 'dma_pfn_offset', 'dma_bus_mask' and 'dma_mask' during the PCI device > > enable fixup. And ultimately allows us to get rid of this device's > > custom DMA functions. > > > > Aside from the code deletion and DMA setup, sta2x11_pdev_to_mapping() is > > moved to avoid warnings whenever CONFIG_PM is not enabled. > > Looks sensible to me: > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > But I can't tested it either, and kinda wonder if this code is actually > still used by anyone.. Maybe Alessandro can shine some light on this (though I wonder his mail is stil valid). [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] x86/PCI: sta2x11: use default DMA address translation 2019-10-31 10:43 ` Nicolas Saenz Julienne @ 2019-10-31 13:59 ` Alessandro Rubini 0 siblings, 0 replies; 12+ messages in thread From: Alessandro Rubini @ 2019-10-31 13:59 UTC (permalink / raw) To: nsaenzjulienne Cc: hch, linux-kernel, tglx, mingo, bp, hpa, x86, bhelgaas, helgaas, linux-pci >> But I can't tested it either, and kinda wonder if this code is actually >> still used by anyone.. I wonder too. > Maybe Alessandro can shine some light on this (though I wonder his > mail is stil valid). Yes, the mail is valid, and I'm busy as usual. Now, this STA2X11 is a chipset by ST-Ericcson that was bringing the AMBA peripherals to the PC world. It was meant to be used as an I/O device in the automotive sector, as far as I know (the audio part had features aimed at automotive installations). I'm sure the chip was never used in standard PC's -- the eval board was a PCIe slot, but that's it. So, I can't test and I don't know if there are users of this chip. If there are users, they are big numbers. I think we can accept any clean-up patch on the code base: if anything goes wrong, the users will surface with a fix when they'll consider an upgrade to their installed systems. /alessndro ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-10-31 14:05 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-10-18 11:00 [PATCH v2 0/2] x86: Get rid of custom DMA functions Nicolas Saenz Julienne 2019-10-18 11:00 ` Nicolas Saenz Julienne 2019-10-18 11:00 ` [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses Nicolas Saenz Julienne 2019-10-18 11:00 ` Nicolas Saenz Julienne 2019-10-30 21:41 ` Christoph Hellwig 2019-10-30 21:41 ` Christoph Hellwig 2019-10-31 10:44 ` Nicolas Saenz Julienne 2019-10-31 10:44 ` Nicolas Saenz Julienne 2019-10-18 11:00 ` [PATCH v2 2/2] x86/PCI: sta2x11: use default DMA address translation Nicolas Saenz Julienne 2019-10-30 21:45 ` Christoph Hellwig 2019-10-31 10:43 ` Nicolas Saenz Julienne 2019-10-31 13:59 ` Alessandro Rubini
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.