clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
---
changes in v2:
Rebase patch[1]https://lkml.org/lkml/2017/8/3/968
and apply this change. Otherwise will merge conflict.
drivers/memory/mtk-smi.c | 5 -
1 file chan
Hi,
here are two patches to add support for 'struct iommu_device'
to the tegra iommu-drivers. This will make the iommu-core
code aware of the hardware iommus that a driver manages.
It will also add the iommus to sysfs and link them to the
devices managed by them.
The patches apply on-top of Robi
From: Joerg Roedel
Add a struct iommu_device to each tegra-gart and register it
with the iommu-core. Also link devices added to the driver
to their respective hardware iommus.
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-gart.c | 26 ++
1 file changed, 26 inserti
From: Joerg Roedel
Add a struct iommu_device to each tegra-smmu and register it
with the iommu-core. Also link devices added to the driver
to their respective hardware iommus.
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-smmu.c | 25 +
1 file changed, 25 insertio
On 08/08/2017 04:21 AM, Will Deacon wrote:
[+ Joerg]
On Tue, Aug 08, 2017 at 11:37:40AM +0100, Robin Murphy wrote:
On 08/08/17 11:26, Artem Savkov wrote:
Commit c54451a "iommu/arm-smmu: Fix the error path in arm_smmu_add_device"
removed fwspec assignment in legacy_binding path as redundant whi
On 08/08/17 01:51, Bob Liu wrote:
> On 2017/8/7 20:52, Jean-Philippe Brucker wrote:
>> Hi Bob,
>>
>> On 07/08/17 13:18, Bob Liu wrote:
>>> On 2017/8/7 18:31, Jean-Philippe Brucker wrote:
On 05/08/17 06:14, valmiki wrote:
[...]
> Hi Jean, Thanks a lot, now i understood the flow. From v
Hi,
Here is a patch-set to support the iommu_device_register()
interface in the fsl-pamu iommu driver. To make it work a
few fixes (Patch 1 and 2), an additional check (Patch 3)
were necessary.
Please review.
Regards,
Joerg
Joerg Roedel (4):
iommu/pamu: Let PAMU depend on PCI
iommu
From: Joerg Roedel
The function probes the PAMU hardware from device-tree
specifications. It initializes global variables and can thus
be only safely called once.
Add a check that that prints a warning when its called more
than once.
Signed-off-by: Joerg Roedel
---
drivers/iommu/fsl_pamu.c |
From: Joerg Roedel
This patch adds a global iommu-handle to the pamu driver and
initializes it at probe time. Also link devices added to the
iommu to this handle.
Signed-off-by: Joerg Roedel
---
drivers/iommu/fsl_pamu.c| 17 +
drivers/iommu/fsl_pamu.h| 3 +++
d
From: Joerg Roedel
The driver does not compile when PCI is not selected, so
make it depend on it.
Signed-off-by: Joerg Roedel
---
drivers/iommu/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f73ff28..e73b7c5 100644
--- a/drivers/
From: Joerg Roedel
Certain address calculations in the driver make the
assumption that phys_addr_t and dma_addr_t are 64 bit wide.
Force this by depending on CONFIG_PHYS_64BIT to be set.
Signed-off-by: Joerg Roedel
---
drivers/iommu/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
An iommu driver for Qualcomm "B" family devices which do implement the
ARM SMMU spec, but not in a way that is compatible with how the arm-smmu
driver is designed. It seems SMMU_SCR1.GASRAE=1 so the global register
space is not accessible. This means it needs to get configuration from
devicetree
From: Stanimir Varbanov
This basically gets the secure page table size, allocates memory for
secure pagetables and passes the physical address to the trusted zone.
Signed-off-by: Stanimir Varbanov
Signed-off-by: Rob Clark
---
drivers/iommu/qcom_iommu.c | 64 +++
Cc: devicet...@vger.kernel.org
Signed-off-by: Rob Clark
Reviewed-by: Rob Herring
---
.../devicetree/bindings/iommu/qcom,iommu.txt | 121 +
1 file changed, 121 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
diff --git a/Document
I want to re-use some of these for qcom_iommu, which has (roughly) the
same context-bank registers.
Signed-off-by: Rob Clark
---
drivers/iommu/arm-smmu-regs.h | 220 ++
drivers/iommu/arm-smmu.c | 211 ++--
2 files c
An iommu driver for Qualcomm "B" family devices which do implement the
ARM SMMU spec, but not in a way that arm-smmu can support.
(I initially added support to arm-smmu, but it was decided that approach
was too intrusive and it would be cleaner to have a separate driver.)
I should note that all t
An iommu driver for Qualcomm "B" family devices which do implement the
ARM SMMU spec, but not in a way that arm-smmu can support.
(I initially added support to arm-smmu, but it was decided that approach
was too intrusive and it would be cleaner to have a separate driver.)
I should note that all t
Hi Josue,
Thank you for the patches.
On Friday 28 Jul 2017 15:49:12 Josue Albarran wrote:
> Hi Joerg,
>
> This series adapts the OMAP IOMMU driver to use the DMA API to flush
> the page table/directory table entries from the CPU caches instead of
> the ARM assembly calls. The patches are baselin
From: Joerg Roedel
Add support for the iommu_device_register interface to make
the s390 hardware iommus visible to the iommu core and in
sysfs.
Signed-off-by: Joerg Roedel
---
arch/s390/include/asm/pci.h | 7 +++
arch/s390/pci/pci.c | 9 -
drivers/iommu/s390-iommu.c | 35
The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCI
On certain HiSilicon platforms (Hip06/Hip07) the GIC ITS and
PCIe RC deviates from the standard implementation and this breaks
PCIe MSI functionality when SMMU is enabled.
The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI
IOMMU drivers can use this to implement their .get_resv_regions callback
for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
Signed-off-by: Shameer Kolothum
---
drivers/iommu/dma-iommu.c | 19 +++
include/linux/dma-iommu.h | 7 +++
2 files changed, 26 insertions
On some platforms ITS address regions have to be excluded from normal
IOVA allocation in that they are detected and decoded in a HW specific
way by system components and so they cannot be considered normal IOVA
address space.
Add an helper function that retrieves ITS address regions through IORT
d
It's ok to disable iommu early in normal kernel or in kdump kernel when
amd_iommu=off is specified. While we should not disable it in kdump kernel
when on-flight dma is still on-going.
Signed-off-by: Baoquan He
---
v9->v10:
Change to call disable_iommus() in normal kernel and the case that
am
When iommu is pre_enabled in kdump kernel, if a device is set up with
guest translations (DTE.GV=1), then don't copy GCR3 table root pointer
but move the device over to an empty guest-cr3 table and handle the
faults in the PPR log (which answer them with INVALID). After all these
PPR faults are rec
Implement call-back is_attach_deferred and use it to defer the
domain attach from iommu driver init to device driver init when
iommu is pre-enabled in kdump kernel.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(
AMD pointed out it's unsafe to update the device-table while iommu
is enabled. It turns out that device-table pointer update is split
up into two 32bit writes in the IOMMU hardware. So updating it while
the IOMMU is enabled could have some nasty side effects.
The safe way to work around this is to
This new call-back will be used to check if the domain attach need be
deferred for now. If yes, the domain attach/detach will return directly.
Signed-off-by: Baoquan He
---
drivers/iommu/iommu.c | 8
include/linux/iommu.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/iom
Move single iommu enabling codes into a wrapper function early_enable_iommu().
This can make later kdump change easier.
And also add iommu_disable_command_buffer and iommu_disable_event_buffer
for later usage.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 42 +++
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 24
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 3 +++
3 files changed, 28 insertions(+)
diff --git a/d
Firstly split the dev table entry copy into address translation part
and irq remapping part. Because these two parts could be enabled
independently.
Secondly do sanity check for address translation and irq remap of old
dev table entry separately.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_
Here several things need be done:
- If iommu is pre-enabled in a normal kernel, just disable it and print
warning.
- If any one of IOMMUs is not pre-enabled in kdump kernel, just continue
as it does in normal kernel.
- If failed to copy dev table of old kernel, continue to proceed as
it doe
When kernel panicked and jump into the kdump kernel, DMA started by the
1st kernel is not stopped, this is called on-flight DMA. In the current
code it will disable iommu and build new translation table and attach
device to it. This will cause:
1. IO_PAGE_FAULT warning message can be seen.
2. tr
Add function copy_dev_tables to copy the old DEV table entries of the panicked
kernel to the new allocated device table. Since all iommus share the same device
table the copy only need be done one time. Here add a new global old_dev_tbl_cpy
to point to the newly allocated device table which the con
This reverts commit 54bd63570484167cb13edf81e31fff107b879981.
We still need the IO_PAGE_FAULT message to warn error after the
issue of on-flight dma in kdump kernel is fixed.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 3 +--
drivers/iommu/amd_iommu_init.c | 9 -
dr
In AMD-Vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining them respectively can make code more read-able. Do it now.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 8
drivers/iommu
On Mon, Aug 07, 2017 at 05:25:44PM +1000, Alexey Kardashevskiy wrote:
> This introduces capabilities to IOMMU groups. The first defined
> capability is IOMMU_GROUP_CAP_ISOLATE_MSIX which tells the IOMMU
> group users that a particular IOMMU group is capable of MSIX message
> filtering; this is usef
On Mon, Aug 07, 2017 at 05:25:48PM +1000, Alexey Kardashevskiy wrote:
1;4803;0c> Some devices have a MSIX BAR not aligned to the system page size
> greater than 4K (like 64k for ppc64) which at the moment prevents
> such MMIO pages from being mapped to the userspace for the sake of
> the MSIX BAR c
38 matches
Mail list logo
