[PATCH v2] memory: mtk-smi: Handle return value of clk_prepare_enable

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.

[PATCH v10 01/12] iommu/amd: Detect pre enabled translation

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

[PATCH v10 07/12] iommu/amd: Do sanity check for address translation and irq remap of old dev table entry

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 ---

[PATCH v10 09/12] iommu/amd: Use is_attach_deferred call-back

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

[PATCH v10 11/12] iommu/amd: Don't copy GCR3 table root pointer

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

[PATCH v10 00/12] Fix the on-flight DMA issue on system with amd iommu

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.

[PATCH v10 05/12] iommu/amd: Add function copy_dev_tables()

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

[PATCH v10 06/12] iommu/amd: copy old trans table from old kernel

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

[PATCH v10 02/12] iommu/amd: add several helper functions

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

[PATCH v10 08/12] iommu: Add is_attach_deferred call-back to iommu-ops

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

[PATCH v10 03/12] Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"

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

[PATCH v10 04/12] iommu/amd: Define bit fields for DTE particularly

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

[PATCH v10 10/12] iommu/amd: Allocate memory below 4G for dev table if translation pre-enabled

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

Re: [RFC PATCH v5 5/5] vfio-pci: Allow to expose MSI-X table to userspace when safe

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

Re: [RFC PATCH v5 1/5] iommu: Add capabilities to a group

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

[PATCH v10 12/12] iommu/amd: Disable iommu only if amd_iommu=off is specified

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

[PATCH v6 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

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

[PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

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

[PATCH v3] iommu/s390: Add support for iommu_device handling

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

[PATCH v6 1/3] ACPI/IORT: Add ITS address regions reservation helper

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

[PATCH v6 2/3] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

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

Re: [PATCH v2] iommu/arm-smmu: fix null-pointer dereference in arm_smmu_add_device

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

[PATCH 0/2] iommu/tegra*: Add support for struct iommu_device

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

[PATCH 2/2] iommu/tegra-gart: Add support for struct iommu_device

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

[PATCH 1/2] iommu/tegra: Add support for struct iommu_device

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

[PATCH 1/4] iommu/pamu: Let PAMU depend on PCI

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

[PATCH 4/4] iommu/pamu: Add support for generic iommu-device

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 +

[PATCH 0/4] iommu/pamu: Support generic iommu-device handles

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

[PATCH 3/4] iommu/pamu: WARN when fsl_pamu_probe() is called more than once

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

[PATCH 2/4] iommu/pamu: Make driver depend on CONFIG_PHYS_64BIT

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

Re: Support SVM without PASID

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

[RESEND PATCH 1/4] Docs: dt: document qcom iommu bindings

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

[RESEND PATCH 4/4] iommu: qcom: initialize secure page table

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

[RESEND PATCH 0/4] iommu: add qcom_iommu for early "B" family devices

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