Re: [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

On Thu, 2017-12-21 at 10:08 +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > Two fixups for mediatek's host bridge: > The first patch fixup the IRQ handle routine to avoid IRQ reentry which > may exist for both MT2712 and MT7622. > The second patch

[PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

From: Honghui Zhang Two fixups for mediatek's host bridge: The first patch fixup the IRQ handle routine to avoid IRQ reentry which may exist for both MT2712 and MT7622. The second patch fixup class type for MT7622. Change Since v1: - Add the second patch. - Make

[PATCH v2 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry

From: Honghui Zhang There maybe a same IRQ reentry scenario after IRQ received in current IRQ handle flow: EP device PCIe host driverEP driver 1. issue an IRQ 2. received IRQ 3. clear IRQ

[PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622

From: Honghui Zhang The host bridge of MT7622 has hardware code the class code to an arbitrary, meaningless value, fix that. Signed-off-by: Honghui Zhang --- drivers/pci/host/pcie-mediatek.c | 12 1 file changed, 12

[PATCH 4/4] iommu/vt-d: Enable 5-level paging mode in the PASID entry

If the CPU has support for 5-level paging enabled and the IOMMU also supports 5-level paging then enable the 5-level paging mode for first- level translations - used when SVM is enabled. Signed-off-by: Sohil Mehta --- drivers/iommu/intel-svm.c | 15 +-- 1 file

[PATCH 3/4] iommu/vt-d: Add a check for 5-level paging support

Add a check to verify IOMMU 5-level paging support. If the CPU supports supports 5-level paging but the IOMMU does not support it then disable SVM by not allocating PASID tables. Signed-off-by: Sohil Mehta --- drivers/iommu/intel-svm.c | 4

[PATCH 1/4] iommu/vt-d: Enable upto 57 bits of domain address width

Update the IOMMU default domain address width to 57 bits. This would enable the IOMMU to do upto 5-levels of paging for second level translations - IOVA translation requests without PASID. Even though the maximum supported address width is being increased to 57, __iommu_calculate_agaw() would set

[PATCH 0/4] Add support for Intel IOMMU 5-level paging

Hi All, Upcoming hardware plans to introduce support for 5-level paging[1]. The support for CPU 5-level paging has already been merged in kernel v4.14. The following patches add support for Intel IOMMU 5-level paging. The patches are based on the Intel Virtualization Technology for Directed I/O

[PATCH 2/4] iommu/vt-d: Add a check for 1GB page support

Add a check to verify IOMMU 1GB page support. If the CPU supports 1GB pages but the IOMMU does not support it then disable SVM by not allocating PASID tables. Signed-off-by: Sohil Mehta --- drivers/iommu/intel-svm.c | 4 include/linux/intel-iommu.h | 1 + 2 files

Re: [PATCH V2] iommu/amd - Set the device table entry PPR bit for IOMMU V2 devices

On 12/20/2017 01:02 PM, Alex Williamson wrote: On Tue, 19 Dec 2017 16:15:41 -0600 Gary R Hook wrote: The AMD IOMMU specification Rev 3.00 (December 2016) introduces a new Enhanced PPR Handling Support (EPHSup) bit in the MMIO register offset 0030h (IOMMU Extended Feature

Re: [PATCH] iommu/amd - Record more information about unknown events

On Mon, 04 Dec 2017 13:52:42 -0600 Gary R Hook wrote: > When an unknown type event occurs, the default information written to > the syslog should dump raw event data. This could provide insight into > the event that occurred. > > Signed-off-by: Gary R Hook

Re: [PATCH V2] iommu/amd - Set the device table entry PPR bit for IOMMU V2 devices

On Tue, 19 Dec 2017 16:15:41 -0600 Gary R Hook wrote: > The AMD IOMMU specification Rev 3.00 (December 2016) introduces a > new Enhanced PPR Handling Support (EPHSup) bit in the MMIO register > offset 0030h (IOMMU Extended Feature Register). > > When EPHSup=1, the IOMMU

Re: [PATCH] iommu: Check the result of iommu_group_get() for NULL

On Mon, 4 Dec 2017 10:22:10 -0700 Jordan Crouse wrote: > The result of iommu_group_get() was being blindly used in both > attach and detach which results in a dereference when trying > to work with an unknown device. > > Signed-off-by: Jordan Crouse

Re: [PATCH v2 0/2] iommu/ipmmu-vmsa: Add r8a779(6|70|95) DT bindings

On Fri, 24 Nov 2017 10:58:02 + Simon Horman wrote: > Update the IPMMU DT binding documentation to include r8a7796 (R-Car M3-W), > r8a77970 (R-Car V3M) and r8a77995 (R-Car D3) compat strings. > > This patch-set is comprised of patches previously included in > *

Re: [PATCH] iommu/vt-d: clean up pr_irq if request_threaded_irq fails

On Wed, 6 Dec 2017 09:49:59 -0700 Jerry Snitselaar wrote: > It is unlikely request_threaded_irq will fail, but if it does for some > reason we should clear iommu->pr_irq in the error path. Also > intel_svm_finish_prq shouldn't try to clean up the page request > interrupt if

Re: [PATCH -next] iommu/tegra-smmu: Fix return value check in tegra_smmu_group_get()

On Wed, Dec 20, 2017 at 09:44:00AM -0700, Alex Williamson wrote: > On Wed, 20 Dec 2017 03:06:09 + > Wei Yongjun wrote: > > > In case of error, the function iommu_group_alloc() returns ERR_PTR() and > > never returns NULL. The NULL test in the return value check should

Re: [PATCH -next] iommu/tegra-smmu: Fix return value check in tegra_smmu_group_get()

On Wed, 20 Dec 2017 03:06:09 + Wei Yongjun wrote: > In case of error, the function iommu_group_alloc() returns ERR_PTR() and > never returns NULL. The NULL test in the return value check should be > replaced with IS_ERR(). > > Fixes: 7f4c9176f760 ("iommu/tegra: Allow

Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset

Hi, Em Fri, 17 Nov 2017 02:58:56 + "Mani, Rajmohan" escreveu: > Here is an update on the IPU3 documentation that we are currently working on. > > Image processing in IPU3 relies on the following. > > 1) HW configuration to enable ISP and > 2) setting customer

Re: [PATCH V1 1/1] iommu: Make sure device's ID array elements are unique

On 19.12.2017 17:37, Alex Williamson wrote: On Tue, 19 Dec 2017 16:20:21 +0100 Tomasz Nowicki wrote: While iterating over DMA aliases for a PCI device, for some rare cases (i.e. PCIe-to-PCI/X bridges) we may get exactly the same ID as initial child device.

Re: [PATCH V1 0/1] Fix kernel panic caused by device ID duplication presented to the IOMMU

Hi Robin, On 19.12.2017 17:34, Robin Murphy wrote: Hi Tomasz, On 19/12/17 15:13, Tomasz Nowicki wrote: Here is my lspci output of ThunderX2 for which I am observing kernel panic coming from SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live): # lspci -vt

Re: [PATCH v2 0/2] iommu/ipmmu-vmsa: Add r8a779(6|70|95) DT bindings

Hi Alex, On Fri, Nov 24, 2017 at 10:58:02AM +, Simon Horman wrote: > Update the IPMMU DT binding documentation to include r8a7796 (R-Car M3-W), > r8a77970 (R-Car V3M) and r8a77995 (R-Car D3) compat strings. > > This patch-set is comprised of patches previously included in > * [PATCH v4 0/3]