Re: [PATCH] iommu: mtk: add common-clk dependency

2016-11-17 Thread Honghui Zhang
On Thu, 2016-11-17 at 15:35 -0800, Stephen Boyd wrote: > On 11/17, Honghui Zhang wrote: > > On Wed, 2016-11-16 at 11:38 -0800, Stephen Boyd wrote: > > > On 11/16, Arnd Bergmann wrote: > > > > After the MT2701 clock driver was added, we get a harmless warning for > > > > the iommu driver that

Re: [PATCH] iommu: mtk: add common-clk dependency

2016-11-17 Thread Stephen Boyd
On 11/17, Honghui Zhang wrote: > On Wed, 2016-11-16 at 11:38 -0800, Stephen Boyd wrote: > > On 11/16, Arnd Bergmann wrote: > > > After the MT2701 clock driver was added, we get a harmless warning for > > > the iommu driver that selects it, when compile-testing without > > > COMMON_CLK. > > > > >

Re: BUG at drivers/iommu/amd_iommu.c:1436!

2016-11-17 Thread Mark Hounschell
On 11/17/2016 04:41 PM, Joerg Roedel wrote: Hi Mark, On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote: Kernel version is 4.8.0. No failure when the IOMMU is disabled. This is an out of tree GPL driver using pci_alloc_consistent/pci_free_consistent. The free causes this. Can

Re: BUG at drivers/iommu/amd_iommu.c:1436!

2016-11-17 Thread Joerg Roedel
On Thu, Nov 17, 2016 at 04:53:24PM -0500, Mark Hounschell wrote: > On 11/17/2016 04:41 PM, Joerg Roedel wrote: > >Hi Mark, > > > >On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote: > >>Kernel version is 4.8.0. No failure when the IOMMU is disabled. This > >>is an out of tree GPL

Re: BUG at drivers/iommu/amd_iommu.c:1436!

2016-11-17 Thread Joerg Roedel
Hi Mark, On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote: > Kernel version is 4.8.0. No failure when the IOMMU is disabled. This > is an out of tree GPL driver using > pci_alloc_consistent/pci_free_consistent. The free causes this. Can you please run the driver with dma-api

BUG at drivers/iommu/amd_iommu.c:1436!

2016-11-17 Thread Mark Hounschell
Kernel version is 4.8.0. No failure when the IOMMU is disabled. This is an out of tree GPL driver using pci_alloc_consistent/pci_free_consistent. The free causes this. The commit is: 2d4c515bf06c9bce87b546279413621f847ef6a3 is the first bad commit commit

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

2016-11-17 Thread Borislav Petkov
On Wed, Nov 09, 2016 at 06:37:08PM -0600, Tom Lendacky wrote: > 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

[iommu:next 1/1] drivers/base/power/main.c:1250:1: error: expected expression before '<<' token

2016-11-17 Thread kbuild test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next head: e74ee64c77fb60776247b9f8f5e478117c32cd0f commit: e74ee64c77fb60776247b9f8f5e478117c32cd0f [1/1] Merge branches 'arm/mediatek', 'x86/amd', 'core' and 'arm/exynos' into next config: x86_64-randconfig-i0-201646

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

2016-11-17 Thread Borislav Petkov
On Wed, Nov 09, 2016 at 06:36:55PM -0600, Tom Lendacky wrote: > This patch adds support to be change the memory encryption attribute for > one or more memory pages. "Add support for changing ..." > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/cacheflush.h

[iommu:next 1/1] drivers/base/power/main.c:1250:1: error: version control conflict marker in file

2016-11-17 Thread kbuild test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next head: e74ee64c77fb60776247b9f8f5e478117c32cd0f commit: e74ee64c77fb60776247b9f8f5e478117c32cd0f [1/1] Merge branches 'arm/mediatek', 'x86/amd', 'core' and 'arm/exynos' into next config: i386-randconfig-a0-201646

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

2016-11-17 Thread Borislav Petkov
On Wed, Nov 09, 2016 at 06:36:31PM -0600, Tom Lendacky wrote: > 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

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

2016-11-17 Thread Borislav Petkov
On Wed, Nov 09, 2016 at 06:36:20PM -0600, Tom Lendacky wrote: > 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

Re: [PATCH] arm: dma-mapping: Reset the device's dma_ops

2016-11-17 Thread Marek Szyprowski
Hi Sricharan, On 2016-11-17 12:20, Sricharan R wrote: arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops() ,dma_ops should be cleared in the teardown path. Otherwise this causes problem when the probe of device is retried after being deferred. The device's iommu structures are

[PATCH] arm: dma-mapping: Reset the device's dma_ops

2016-11-17 Thread Sricharan R
arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops() ,dma_ops should be cleared in the teardown path. Otherwise this causes problem when the probe of device is retried after being deferred. The device's iommu structures are cleared after EPROBEDEFER error, but on the next try dma_ops