Re: [v16, 0/7] Fix eSDHC host version register bug

On Thu, 2016-11-10 at 04:11 +, Y.B. Lu wrote: > > > > -Original Message- > > From: Y.B. Lu > > Sent: Thursday, November 10, 2016 12:06 PM > > To: 'Scott Wood'; Ulf Hansson > > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org; > > devicet...@vger.kernel.org;

RE: [v16, 0/7] Fix eSDHC host version register bug

> -Original Message- > From: Y.B. Lu > Sent: Thursday, November 10, 2016 12:06 PM > To: 'Scott Wood'; Ulf Hansson > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; linux-clk;

RE: [v16, 0/7] Fix eSDHC host version register bug

> -Original Message- > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- > ow...@vger.kernel.org] On Behalf Of Scott Wood > Sent: Thursday, November 10, 2016 11:55 AM > To: Ulf Hansson; Y.B. Lu > Cc: linux-mmc; Arnd Bergmann; linuxppc-...@lists.ozlabs.org; >

Re: [v16, 0/7] Fix eSDHC host version register bug

On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote: > - i2c-list > > On 9 November 2016 at 04:14, Yangbo Lu wrote: > > > > This patchset is used to fix a host version register bug in the T4240- > > R1.0-R2.0 > > eSDHC controller. To match the SoC version and revision, 15

Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support

On Thu, Nov 10, 2016 at 01:36:29AM +0100, Rafael J. Wysocki wrote: > On Wed, Nov 9, 2016 at 4:07 PM, Marek Szyprowski > wrote: > > Hi Luis, > > > > > > On 2016-11-08 23:14, Luis R. Rodriguez wrote: > >> > >> On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski

Re: Summary of LPC guest MSI discussion in Santa Fe

On Thu, 10 Nov 2016 01:14:42 +0100 Auger Eric wrote: > Hi, > > On 10/11/2016 00:59, Alex Williamson wrote: > > On Wed, 9 Nov 2016 23:38:50 + > > Will Deacon wrote: > > > >> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote: >

[RFC PATCH v3 18/20] x86: Access the setup data through debugfs un-encrypted

Since the setup data is in memory in the clear, it must be accessed as un-encrypted. Always use ioremap (similar to sysfs setup data support) to map the data. Signed-off-by: Tom Lendacky --- arch/x86/kernel/kdebugfs.c | 30 +++--- 1 file

[RFC PATCH v3 19/20] x86: Add support to make use of Secure Memory Encryption

This patch adds the support to check if SME has been enabled and if the mem_encrypt=on command line option is set. If both of these conditions are true, then the encryption mask is set and the kernel is encrypted "in place." Signed-off-by: Tom Lendacky ---

[RFC PATCH v3 16/20] x86: Do not specify encrypted memory for video mappings

Since video memory needs to be accessed unencrypted be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/vga.h | 13 + drivers/gpu/drm/drm_gem.c|2 ++

[RFC PATCH v3 14/20] iommu/amd: Disable AMD IOMMU if memory encryption is active

For now, disable the AMD IOMMU if memory encryption is active. A future patch will re-enable the function with full memory encryption support. Signed-off-by: Tom Lendacky --- drivers/iommu/amd_iommu_init.c |5 + 1 file changed, 5 insertions(+) diff --git

[RFC PATCH v3 17/20] x86/kvm: Enable Secure Memory Encryption of nested page tables

Update the KVM support to include the memory encryption mask when creating and using nested page tables. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/kvm_host.h |3 ++- arch/x86/kvm/mmu.c |8 ++-- arch/x86/kvm/vmx.c |3

[RFC PATCH v3 11/20] x86: Add support for changing memory encryption attribute

This patch adds support to be change the memory encryption attribute for one or more memory pages. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/cacheflush.h |3 + arch/x86/include/asm/mem_encrypt.h | 13 ++ arch/x86/mm/mem_encrypt.c | 43

[RFC PATCH v3 12/20] x86: Decrypt trampoline area if memory encryption is active

When Secure Memory Encryption is enabled, the trampoline area must not be encrypted. A CPU running in real mode will not be able to decrypt memory that has been encrypted because it will not be able to use addresses with the memory encryption mask. Signed-off-by: Tom Lendacky

[RFC PATCH v3 13/20] x86: DMA support for memory encryption

Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create un-encrypted bounce buffers for use by these devices.

[RFC PATCH v3 15/20] x86: Check for memory encryption on the APs

Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP then do not allow the AP to continue start up. Signed-off-by: Tom Lendacky ---

[RFC PATCH v3 09/20] x86: Insure that boot memory areas are mapped properly

The boot data and command line data are present in memory in an un-encrypted state and are copied early in the boot process. The early page fault support will map these areas as encrypted, so before attempting to copy them, add unencrypted mappings so the data is accessed properly when copied.

[RFC PATCH v3 10/20] Add support to access boot related data in the clear

Boot data (such as EFI related data) is not encrypted when the system is booted and needs to be accessed unencrypted. Add support to apply the proper attributes to the EFI page tables and to the early_memremap and memremap APIs to identify the type of data being accessed so that the proper

Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support

On Wed, Nov 9, 2016 at 4:07 PM, Marek Szyprowski wrote: > Hi Luis, > > > On 2016-11-08 23:14, Luis R. Rodriguez wrote: >> >> On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote: >>> >>> Hi Luis >>> >>> >>> On 2016-10-06 19:37, Luis R. Rodriguez wrote:

[RFC PATCH v3 07/20] x86: Provide general kernel support for memory encryption

Adding general kernel support for memory encryption includes: - Modify and create some page table macros to include the Secure Memory Encryption (SME) memory encryption mask - Modify and create some macros for calculating physical and virtual memory addresses - Provide an SME initialization

[RFC PATCH v3 08/20] x86: Add support for early encryption/decryption of memory

Add support to be able to either encrypt or decrypt data in place during the early stages of booting the kernel. This does not change the memory encryption attribute - it is used for ensuring that data present in either an encrypted or un-encrypted memory area is in the proper state (for example

[RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/msr-index.h |2 ++ arch/x86/kernel/cpu/common.c | 30

[RFC PATCH v3 05/20] x86: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky

[RFC PATCH v3 06/20] x86: Add support to enable SME during early boot processing

This patch adds support to the early boot code to use Secure Memory Encryption (SME). Support is added to update the early pagetables with the memory encryption mask and to encrypt the kernel in place. The routines to set the encryption mask and perform the encryption are stub routines for now

[RFC PATCH v3 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)

This patch adds a Documenation entry to decribe the AMD Secure Memory Encryption (SME) feature. Signed-off-by: Tom Lendacky --- Documentation/kernel-parameters.txt |5 +++ Documentation/x86/amd-memory-encryption.txt | 40 +++ 2

[RFC PATCH v3 00/20] x86: Secure Memory Encryption (AMD)

This RFC patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be

[RFC PATCH v3 03/20] x86: Add the Secure Memory Encryption cpu feature

Update the cpu features to include identifying and reporting on the Secure Memory Encryption feature. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/cpufeatures.h |1 + arch/x86/kernel/cpu/scattered.c|1 + 2 files changed, 2 insertions(+) diff --git

Re: Summary of LPC guest MSI discussion in Santa Fe

Hi, On 10/11/2016 00:59, Alex Williamson wrote: > On Wed, 9 Nov 2016 23:38:50 + > Will Deacon wrote: > >> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote: >>> On Wed, 9 Nov 2016 22:25:22 + >>> Will Deacon wrote: >>> On

Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm

On Thu, Nov 10, 2016 at 01:05:42AM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 10, 2016 at 12:55 AM, Luis R. Rodriguez wrote: > > On Tue, Nov 08, 2016 at 04:30:44PM +0100, Lukas Wunner wrote: > >> On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote: > >> > On

Re: Summary of LPC guest MSI discussion in Santa Fe

On Wed, 9 Nov 2016 23:38:50 + Will Deacon wrote: > On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote: > > On Wed, 9 Nov 2016 22:25:22 + > > Will Deacon wrote: > > > > > On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson

Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm

On Tue, Nov 8, 2016 at 4:30 PM, Lukas Wunner wrote: > On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote: >> On 2016-11-07 22:47, Luis R. Rodriguez wrote: >> > Has there been any review of the existing similar solutions out there >> > such as the DRM / audio

Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm

On Tue, Nov 08, 2016 at 04:30:44PM +0100, Lukas Wunner wrote: > On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote: > > On 2016-11-07 22:47, Luis R. Rodriguez wrote: > > > Has there been any review of the existing similar solutions out there > > > such as the DRM / audio component

Re: [PATCH v6 7/7] iommu/exynos: Use device dependency links to control runtime pm

On Thu, Nov 10, 2016 at 12:31 AM, Luis R. Rodriguez wrote: > On Tue, Nov 08, 2016 at 02:29:24PM +0100, Marek Szyprowski wrote: >> This patch uses recently introduced device dependency links to track the >> runtime pm state of the master's device. The goal is to let SYSMMU >>

Re: Summary of LPC guest MSI discussion in Santa Fe

On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote: > On Wed, 9 Nov 2016 22:25:22 + > Will Deacon wrote: > > > On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote: > > > On Wed, 9 Nov 2016 20:31:45 + > > > Will Deacon

Re: [PATCH v7 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type

On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi wrote: > On systems booting with a device tree, every struct device is associated > with a struct device_node, that provides its DT firmware representation. > The device node can be used in generic kernel contexts (eg

Re: [PATCH v7 00/16] ACPI IORT ARM SMMU support

Hi Lorenzo, On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi wrote: > This patch series is v7 of a previous posting: > > https://lkml.org/lkml/2016/10/18/506 I don't see anything objectionable in this series. Please let me know which patches in particular to look at

Re: [PATCH v6 7/7] iommu/exynos: Use device dependency links to control runtime pm

On Tue, Nov 08, 2016 at 02:29:24PM +0100, Marek Szyprowski wrote: > This patch uses recently introduced device dependency links to track the > runtime pm state of the master's device. The goal is to let SYSMMU > controller device's runtime PM to follow the runtime PM state of the > respective

Re: Summary of LPC guest MSI discussion in Santa Fe

On Wed, 9 Nov 2016 22:25:22 + Will Deacon wrote: > On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote: > > On Wed, 9 Nov 2016 20:31:45 + > > Will Deacon wrote: > > > On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall

Re: Summary of LPC guest MSI discussion in Santa Fe

On Wed, 9 Nov 2016 20:31:45 + Will Deacon wrote: > On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote: > > > > (I suppose it's technically possible to get around this issue by letting > > QEMU place RAM wherever it wants but tell the guest to never use a >

Re: Summary of LPC guest MSI discussion in Santa Fe

On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote: > On Wed, Nov 09, 2016 at 01:59:07PM -0500, Don Dutile wrote: > > On 11/09/2016 12:03 PM, Will Deacon wrote: > > >On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote: > > >>On 11/08/2016 06:35 PM, Alex Williamson wrote: > >

Re: Summary of LPC guest MSI discussion in Santa Fe

On Wed, 9 Nov 2016 20:23:03 +0100 Christoffer Dall wrote: > On Wed, Nov 09, 2016 at 01:59:07PM -0500, Don Dutile wrote: > > On 11/09/2016 12:03 PM, Will Deacon wrote: > > >On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote: > > >>On 11/08/2016 06:35 PM,

Re: Summary of LPC guest MSI discussion in Santa Fe

On 11/09/2016 12:03 PM, Will Deacon wrote: On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote: On 11/08/2016 06:35 PM, Alex Williamson wrote: On Tue, 8 Nov 2016 21:29:22 +0100 Christoffer Dall wrote: Is my understanding correct, that you need to tell

Re: [PATCH 1/5] iommu: Allow taking a reference on a group directly

On Wed, Nov 09, 2016 at 05:46:16PM +, Robin Murphy wrote: > On 09/11/16 17:25, Will Deacon wrote: > > On Wed, Nov 09, 2016 at 12:47:24PM +, Robin Murphy wrote: > >> iommu_group_get_for_dev() expects that the IOMMU driver's device_group > >> callback return a group with a reference held for

Re: [PATCH 1/5] iommu: Allow taking a reference on a group directly

On Wed, Nov 09, 2016 at 12:47:24PM +, Robin Murphy wrote: > iommu_group_get_for_dev() expects that the IOMMU driver's device_group > callback return a group with a reference held for the given device. > Whilst allocating a new group is fine, and pci_device_group() correctly > handles reusing

Re: Summary of LPC guest MSI discussion in Santa Fe

On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote: > On 11/08/2016 06:35 PM, Alex Williamson wrote: > >On Tue, 8 Nov 2016 21:29:22 +0100 > >Christoffer Dall wrote: > >>Is my understanding correct, that you need to tell userspace about the > >>location of the

Re: [PATCH V3 0/8] IOMMU probe deferral support

On Wed, Nov 09, 2016 at 11:54:20AM +0530, Sricharan wrote: > >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c > >> index 71ce4b6..a1d0b3c 100644 > >> --- a/drivers/iommu/arm-smmu.c > >> +++ b/drivers/iommu/arm-smmu.c > >> @@ -1516,8 +1516,10 @@ static struct iommu_group > >>

Re: [PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure

On 09/11/16 14:19, Lorenzo Pieralisi wrote: > On DT based systems, the of_dma_configure() API implements DMA > configuration for a given device. On ACPI systems an API equivalent to > of_dma_configure() is missing which implies that it is currently not > possible to set-up DMA operations for

Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support

Hi Luis, On 2016-11-08 23:14, Luis R. Rodriguez wrote: On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote: Hi Luis On 2016-10-06 19:37, Luis R. Rodriguez wrote: On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote: This patch uses recently introduced device links

Re: [PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage

On 09/11/16 14:19, Lorenzo Pieralisi wrote: > Current ARM SMMU v3 driver rely on the struct device.of_node pointer for > device look-up and iommu_ops retrieval. > > In preparation for ACPI probing enablement, convert the driver to use > the struct device.fwnode member for device and iommu_ops

Re: [PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage

On 09/11/16 14:19, Lorenzo Pieralisi wrote: > Current ARM SMMU driver rely on the struct device.of_node pointer for > device look-up and iommu_ops retrieval. > > In preparation for ACPI probing enablement, convert the driver to use > the struct device.fwnode member for device and iommu_ops

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On 09/11/16 14:19, Lorenzo Pieralisi wrote: > The of_iommu_{set/get}_ops() API is used to associate a device > tree node with a specific set of IOMMU operations. The same > kernel interface is required on systems booting with ACPI, where > devices are not associated with a device tree node,

[PATCH v7 08/16] drivers: acpi: iort: add node match function

Device drivers (eg ARM SMMU) need to know if a specific component is part of the IORT table, so that kernel data structures are not initialized at initcalls time if the respective component is not part of the IORT table. To this end, this patch adds a trivial function that allows detecting if a

[PATCH v7 13/16] drivers: iommu: arm-smmu: add IORT configuration

In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU components. Add static configuration

[PATCH v7 15/16] drivers: acpi: iort: add single mapping function

The current IORT id mapping API requires components to provide an input requester ID (a Bus-Device-Function (BDF) identifier for PCI devices) to translate an input identifier to an output identifier through an IORT range mapping. Named components do not have an identifiable source ID therefore

[PATCH v7 14/16] drivers: acpi: iort: replace rid map type with type mask

IORT tables provide data that allow the kernel to carry out device ID mappings between endpoints and system components (eg interrupt controllers, IOMMUs). When the mapping for a given device ID is carried out, the translation mechanism is done on a per-subsystem basis rather than a component

[PATCH v7 12/16] drivers: iommu: arm-smmu: split probe functions into DT/generic portions

Current ARM SMMU probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU driver features. In order to allow probing the ARM SMMU with other firmwares than DT, this patch splits the ARM SMMU init functions into DT and HW specific portions

[PATCH v7 03/16] drivers: acpi: iort: add support for IOMMU fwnode registration

The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world) components that allow creating the kernel data structures required to probe and initialize the IOMMU devices. This patch provides support in the IORT kernel code to register IOMMU components and their respective fwnode.

[PATCH v7 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing

Since commit e647b532275b ("ACPI: Add early device probing infrastructure") the kernel has gained the infrastructure that allows adding linker script section entries to execute ACPI driver callbacks (ie probe routines) for all subsystems that register a table entry in the respective kernel section

[PATCH v7 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type

On systems booting with a device tree, every struct device is associated with a struct device_node, that provides its DT firmware representation. The device node can be used in generic kernel contexts (eg IRQ translation, IOMMU streamid mapping), to retrieve the properties associated with the

[PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure

On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This

[PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage

Current ARM SMMU driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used also

[PATCH v7 10/16] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions

Current ARM SMMUv3 probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU v3 driver features. In order to allow probing the ARM SMMUv3 with other firmwares than DT, this patch splits the ARM SMMUv3 init functions into DT and HW specific

[PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage

Current ARM SMMU v3 driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used

[PATCH v7 09/16] drivers: acpi: iort: add support for ARM SMMU platform devices creation

In ARM ACPI systems, IOMMU components are specified through static IORT table entries. In order to create platform devices for the corresponding ARM SMMU components, IORT kernel code should be made able to parse IORT table entries and create platform devices dynamically. This patch adds the

[PATCH v7 00/16] ACPI IORT ARM SMMU support

This patch series is v7 of a previous posting: https://lkml.org/lkml/2016/10/18/506 v6 -> v7 - Rebased against v4.9-rc4 - Fixed IORT probing on ACPI systems with missing IORT table - Fixed SMMUv1/v2 global interrupt detection - Updated iommu_ops firmware look-up

RE: [PATCH 1/5] iommu: Allow taking a reference on a group directly

Hi, >-Original Message- >From: Robin Murphy [mailto:robin.mur...@arm.com] >Sent: Wednesday, November 09, 2016 6:17 PM >To: j...@8bytes.org >Cc: will.dea...@arm.com; sricha...@codeaurora.org; >iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org >Subject: [PATCH 1/5]

Re: [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration

Hi Lorenzo, On 18.10.2016 18:04, Lorenzo Pieralisi wrote: In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure

[PATCH 5/5] iommu/mediatek: Fix M4Uv1 group refcounting

For each subsequent device assigned to the m4u_group after its initial allocation, we need to take an additional reference. Signed-off-by: Robin Murphy --- drivers/iommu/mtk_iommu_v1.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/mtk_iommu_v1.c

[PATCH 3/5] iommu/amd: Fix group refcounting

If acpihid_device_group() finds an existing group for the relevant devid, it should be taking an additional reference on that group. Signed-off-by: Robin Murphy --- drivers/iommu/amd_iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/amd_iommu.c

[PATCH 4/5] iommu/mediatek: Fix M4Uv2 group refcounting

For each subsequent device assigned to the m4u_group after its initial allocation, we need to take an additional reference. Signed-off-by: Robin Murphy --- drivers/iommu/mtk_iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/mtk_iommu.c

[PATCH 2/5] iommu/arm-smmu: Fix group refcounting

When arm_smmu_device_group() finds an existing group due to Stream ID aliasing, it should be taking an additional reference on that group. Reported-by: Sricharan R Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu.c | 2 +- 1 file changed, 1

[PATCH 1/5] iommu: Allow taking a reference on a group directly

iommu_group_get_for_dev() expects that the IOMMU driver's device_group callback return a group with a reference held for the given device. Whilst allocating a new group is fine, and pci_device_group() correctly handles reusing an existing group, there is no general means for IOMMU drivers doing

Re: [v16, 0/7] Fix eSDHC host version register bug

Can you please update your CC list? There is nothing i2c related in this patch series, so you could drop the i2c-list. signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org