On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels boot and the P.A. Semi
Ethernet works! :-) Thanks a lot!
I also tested it in a virtual e5500 QEMU machine today. Unfortunatel
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
> On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
>> On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
>>> I tested the whole series today. The kernels boot and the P.A. Semi
>>> Ethernet works! :-) Thank
Hello,
Wen, thank you for the patch.
On Mon, Feb 11, 2019 at 11:24:15AM +0100, j...@8bytes.org wrote:
> Adding a few more people to Cc.
>
> On Sun, Feb 03, 2019 at 10:27:09AM +, wen yang wrote:
> > Make sure to drop the reference to the device taken by
> > of_find_device_by_node() on driver
From: Christoph Hellwig
Date: Mon, 11 Feb 2019 14:19:56 +0100
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and various
Hello,
Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_
On Tue, Feb 05, 2019 at 10:27:00AM +0530, Srinath Mannam wrote:
> In the current implementation, config read output data 0x0001 is
> assumed as CRS completion. But sometimes 0x0001 can be a valid data.
>
> IPROC PCIe host controller has a register to show config read request
> status flags
On Tue, Feb 05, 2019 at 10:27:01AM +0530, Srinath Mannam wrote:
> Add configuration to support IPROC PCIe host controller outbound memory
> window mapping with SOC address range inside 4GB boundary, which is 32 bit
> AXI address.
I do not understand what this means, explain it to me and rewrite th
On Fri, Jan 18, 2019 at 03:10:26PM +0800, Dongli Zhang wrote:
> Fix the comment as swiotlb_bounce() is used to copy from original dma
> location to swiotlb buffer during swiotlb_tbl_map_single(), while to
> copy from swiotlb buffer to original dma location during
> swiotlb_tbl_unmap_single().
I qu
* Christoph Hellwig [190212 07:27]:
> Instead of setting up a kernel pointer to track the current PIO address,
> track the offset in the current page, and do an atomic kmap for the page
> while doing the actual PIO operations.
I'm currently having issues booting my test devices (770 and n8x0)
wit
On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels
On 12 February 2019 at 8:31PM, Christian Zigotzky wrote:
On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigo
Great! I owe you a night worth of beers at a conference or if
you come anywhere near Innsbruck!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote:
>
> The OF_RESERVED_MEM can be used if we have either CMA or the generic
> declare coherent code built and we support the early flattened DT.
>
> So don't bother making it a user visible options that is selected
> by most configs that fit th
On Mon, Feb 11, 2019 at 7:36 AM Christoph Hellwig wrote:
>
> This function is only used in of_reserved_mem.c, and never overridden
> despite the __weak marker.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/of/of_reserved_mem.c| 2 +-
> include/linux/of_reserved_mem.h | 7 ---
> 2
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote:
>
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly. So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
> users. Also rename the
Hi Lorenzo,
Thanks for review, please see my comments below inline.
On Tue, Feb 12, 2019 at 11:42 PM Lorenzo Pieralisi
wrote:
>
> On Tue, Feb 05, 2019 at 10:27:00AM +0530, Srinath Mannam wrote:
> > In the current implementation, config read output data 0x0001 is
> > assumed as CRS completion
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the secu
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framework
is designed to be independent of the platform IOMMU support. As the
result, the DMA isolation relies on the mdev parent device in a
vendor specific way.
There a
This moves intel_iommu_enable_pasid() out of the scope of
CONFIG_INTEL_IOMMU_SVM with more and more features requiring
pasid function.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 22 +++---
drivers/iommu/intel-svm.c |
This part of code could be used by both normal and aux
domain specific attach entries. Hence move them into a
common function to avoid duplication.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 60 ++---
1
This adds support to return the default pasid associated with
an auxiliary domain. The PCI device which is bound with this
domain should use this value as the pasid for all DMA requests
of the subset of device which is isolated and protected with
this domain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevi
This adds the iommu ops entries for aux-domain per-device
feature query and enable/disable.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Sanjay Kumar
Signed-off-by: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 159
incl
A parent device might create different types of mediated
devices. For example, a mediated device could be created
by the parent device with full isolation and protection
provided by the IOMMU. One usage case could be found on
Intel platforms where a mediated device is an assignable
subset of a PCI,
When multiple domains per device has been enabled by the
device driver, the device will tag the default PASID for
the domain to all DMA traffics out of the subset of this
device; and the IOMMU should translate the DMA requests
in PASID granularity.
This adds the intel_iommu_aux_attach/detach_devic
This adds the support to determine the isolation type
of a mediated device group by checking whether it has
an iommu device. If an iommu device exists, an iommu
domain will be allocated and then attached to the iommu
device. Otherwise, keep the same behavior as it is.
Cc: Ashok Raj
Cc: Jacob Pan
This adds helpers to attach or detach a domain to a
group. This will replace iommu_attach_group() which
only works for non-mdev devices.
If a domain is attaching to a group which includes the
mediated devices, it should attach to the iommu device
(a pci device which represents the mdev in iommu sc
Hi Lorenzo,
Thanks for review, please see my comments below inline.
On Wed, Feb 13, 2019 at 12:07 AM Lorenzo Pieralisi
wrote:
>
> On Tue, Feb 05, 2019 at 10:27:01AM +0530, Srinath Mannam wrote:
> > Add configuration to support IPROC PCIe host controller outbound memory
> > window mapping with SO
Hi all,
this series switches the powerpc port to use the generic swiotlb and
noncoherent dma ops, and to use more generic code for the coherent
direct mapping, as well as removing a lot of dead code.
As this series is very large and depends on the dma-mapping tree I've
also published a git tree:
vio_dma_mapping_ops currently does a lot of indirect calls through
dma_iommu_ops, which not only make the code harder to follow but are
also expensive in the post-spectre world. Unwind the indirect calls
by calling the ppc_iommu_* or iommu_* APIs directly applicable, or
just use the dma_iommu_* me
If there is no ZONE_DMA32 we might need GFP_DMA to be able to
allocate memory that satisfies a 32-bit DMA mask.
Reported-by: Christian Zigotzky
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
kernel/dma/direct.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
Add a new iommu_bypass flag to struct dev_archdata so that the dma_iommu
implementation can handle the direct mapping transparently instead of
switiching ops around. Setting of this flag is controlled by new
pci_controller_ops method.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzk
Use the generic iommu bypass code instead of overriding set_dma_mask.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/iommu.c | 100 +++--
1 file changed, 27 insertions(+), 73 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerp
The pasemi driver never set a DMA mask, and given that the powerpc
DMA mapping routines never check it this worked ok so far. But the
generic dma-direct code which I plan to switch on for powerpc checks
the DMA mask and fails unsupported mapping requests, so we need to
make sure the proper 64-bit
Call dma_get_required_mask_pSeriesLP directly instead of dma_iommu_ops
to simply the code a bit.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/
Configure the dma settings at device setup time, and stop playing games
with get_pci_dma_ops. This prepares for using the common dma_configure
code later on.
Includes fixes from Michael Ellerman.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/cell/iommu.c | 24 +++-
This function is completely bogus - the fact that two PCIe devices come
from the same vendor has absolutely nothing to say about the DMA
capabilities and characteristics.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/powernv/pci-ioda.c | 28 ++-
1 file changed,
If dart_init failed we didn't have a chance to setup dma or controller
ops yet, so there is no point in resetting them.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/sysdev/dart_iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/dart_i
These devices are not PCIe devices and do not have associated dma map
ops, so this is just dead code.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/powernv/pci-ioda.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/power
Use the generic iommu bypass code instead of overriding set_dma_mask.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/powernv/pci-ioda.c | 95 ++-
1 file changed, 25 insertions(+), 70 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/pow
Use the generic iommu bypass code instead of overriding set_dma_mask.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/sysdev/dart_iommu.c | 47
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysde
Unused now.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/pci-bridge.h | 2 --
arch/powerpc/kernel/dma.c | 7 ---
2 files changed, 9 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 236a7460b6ec..98e8b
The ppc_md and pci_controller_ops methods are unused now and can be
removed. The dma_nommu implementation is generic to the generic one
except for using max_pfn instead of calling into the memblock API,
and all other dma_map_ops instances implement a method of their own.
Signed-off-by: Christoph
This gets rid of a lot of clumsy code and finally allows us to mark
dma_iommu_ops const.
Includes fixes from Michael Ellerman.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping.h | 2 +-
arch/powerpc/include/asm/iommu.h | 6 ++
arch/powerpc/kernel/dma-iommu.c
All iommu capable platforms now always use the iommu code with the
internal bypass, so there is not need for this magic anymore.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/Kconfig | 4 ---
arch/powerpc/kernel/dma.c | 68 ++--
The max_direct_dma_addr duplicates the bus_dma_mask field in struct
device. Use the generic field instead.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/device.h | 3 ---
arch/powerpc/include/asm/dma-direct.h | 4 +---
arch/powerpc/kernel/dma
Use the standard portable helper instead of the powerpc specific one,
which is about to go away.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
Tested-by: Christian Zigotzky
---
arch/powerpc/kernel/dma.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
This function is only used by the Cell iommu code, which can keep track
if it is using the iommu internally just as good.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/pci.h | 2 --
arch/powerpc/kernel/pci-common.c| 6 --
arch/powerpc
This function is identical to the generic dma_direct_get_required_mask,
except that the generic version also takes the bus_dma_mask account,
which could lead to incorrect results in the powerpc version.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/
pci_dma_dev_setup_swiotlb is only used by the fsl_pci code, and closely
related to it, so fsl_pci.c seems like a better place for it.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/swiotlb.h | 2 --
arch/powerpc/kernel/dma-swiotlb.c | 11 --
Instead of letting the architecture supply all of dma_set_mask just
give it an additional hook selected by Kconfig.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/dma-mapping.h | 2 --
arch/powerpc/incl
We need to compare the last byte in the dma range and not the one after it
for the bus_dma_mask, just like we do for the regular dma_mask. Fix this
cleanly by merging the two comparisms into one.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-di
The only user left is powerpc, but even there the generic dma-direct
version works just as well, given that we guarantee that the swiotlb
buffer must always be addressable.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/kernel/dma-swiotlb.c | 2 +-
include/linu
Now that we've switched all the powerpc nommu and swiotlb methods to
use the generic dma_direct_* calls we can remove these ops vectors
entirely and rely on the common direct mapping bypass that avoids
indirect function calls entirely. This also allows to remove a whole
lot of boilerplate code rel
Switch the streaming DMA mapping and ownership transfer methods to the
functionally identical dma_direct_ versions. Factor the cache
maintainance helpers into the form expected by the common code for that.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/
Just fold the calculation into __phys_to_dma/__dma_to_phys as those are
the only places that should know about it.
Signed-off-by: Christoph Hellwig
Acked-by: Benjamin Herrenschmidt
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-direct.h | 8 ++--
arch/powerpc/include/asm/
There is no need to provide anything but get_arch_dma_ops to
. More the remaining declarations to
and drop all the includes.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-mapping.h| 29 ---
arch/powerpc/include/asm/iomm
This function is largely identical to the generic version used
everywhere else. Replace it with the generic version.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-mapping.h | 1 -
arch/powerpc/kernel/dma-iommu.c| 2 +-
arch/powerpc/ke
There is no good reason for this helper, just opencode it.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/asm/dma-mapping.h| 6 --
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 4 ++--
arch/powerpc/
The generic code allows a few nice things such as node local allocations
and dipping into the CMA area. The lookup of the right zone for a given
dma mask works a little different, but the results should be the same.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerp
The coherent cache version of this function already is functionally
identicall to the default version, and by defining the
arch_dma_coherent_to_pfn hook the same is ture for the noncoherent
version as well.
Signed-off-by: Christoph Hellwig
Tested-by: Christian Zigotzky
---
arch/powerpc/include/
60 matches
Mail list logo
