在 2018年06月19日 22:46, lijiang 写道:
> 在 2018年06月19日 11:16, Dave Young 写道:
>> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
>>> In kdump mode, we need to dump the old memory into vmcore file,
>>> if SME is enabled in the first kernel, we must remap the old
>>> memory in encrypted manner, which will be au
On Wed, Jun 20, 2018 at 07:52:53AM +0900, Linus Torvalds wrote:
> On Tue, Jun 19, 2018 at 1:44 PM Christoph Hellwig wrote:
> >
> > below is a rename of the assorted dma-mapping files to that they live
> > under kernel/dma and lose their dma-* prefixes. If there is any time
> > to do this it is ri
On 06/19/2018 05:15 PM, Ricardo Neri wrote:
> On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote:
>> On Fri, 15 Jun 2018, Ricardo Neri wrote:
>>> On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote:
On Thu, 14 Jun 2018, Ricardo Neri wrote:
> Alternatively, there co
On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote:
> On Fri, 15 Jun 2018, Ricardo Neri wrote:
> > On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote:
> > > On Thu, 14 Jun 2018, Ricardo Neri wrote:
> > > > Alternatively, there could be a counter that skips reading the HPET
Hi Christoph,
On Fri, Jun 15, 2018 at 01:08:47PM +0200, Christoph Hellwig wrote:
> -static inline unsigned long plat_dma_addr_to_phys(struct device *dev,
> - dma_addr_t dma_addr)
> -{
> -#if defined(CONFIG_CPU_LOONGSON2F) && defined(CONFIG_64BIT)
> - return (dma_addr > 0x8fff) ? dma_ad
On Tue, Jun 19, 2018 at 1:44 PM Christoph Hellwig wrote:
>
> below is a rename of the assorted dma-mapping files to that they live
> under kernel/dma and lose their dma-* prefixes. If there is any time
> to do this it is right after -rc1, so let me know if this is something
> you'd take.
I iwas
Hi Suravee,
I love your patch! Perhaps something to improve:
[auto build test WARNING on iommu/next]
[also build test WARNING on v4.18-rc1 next-20180619]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
In case the AMD IOMMU driver fails to enable interrupt, it currently
results in failure to boot due to invalid dma_ops for buses and devices
previously set when they were added to the IOMMU.
Therefore, fix this by unsetting the bus's iommu, and setup end-point
devices to use dma_direct_ops.
Signe
This interface allows removal of IOMMU from a bus if needed.
For example, when the IOMMU driver fails to initialize, it should
unassociate itself from the bus (i.e. removing IOMMU groups and
unregister bus notifier block).
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/iommu.c | 22
Currently, AMD system will not boot if the AMD IOMMU driver initialization
fails. This is mainly due to devices' dma_ops are still configured to use
amd_iommu_ops. Instead, the driver should retore the device dma_ops to
the default one as part of its error recovery.
However, other clean ups should
在 2018年06月19日 11:16, Dave Young 写道:
> On 06/16/18 at 04:27pm, Lianbo Jiang wrote:
>> In kdump mode, we need to dump the old memory into vmcore file,
>> if SME is enabled in the first kernel, we must remap the old
>> memory in encrypted manner, which will be automatically decrypted
>> when we read f
On Tue, Jun 19, 2018 at 01:52:24PM +0100, Jean-Philippe Brucker wrote:
> When run on a 64-bit system in selftest, the v7s driver may obtain page
> table with physical addresses larger than 32-bit. Level-2 tables are 1KB
> and are are allocated with slab, which doesn't accept the GFP_DMA32
> flag. C
When run on a 64-bit system in selftest, the v7s driver may obtain page
table with physical addresses larger than 32-bit. Level-2 tables are 1KB
and are are allocated with slab, which doesn't accept the GFP_DMA32
flag. Currently map() truncates the address written in the PTE, causing
iova_to_phys()
On Mon, Jun 18, 2018 at 12:27:54PM +0100, Jean-Philippe Brucker wrote:
> Commit 4b123757eeaa ("iommu/io-pgtable-arm: Make allocations
> NUMA-aware") added a NUMA hint to page table allocation, but the pgtable
> selftest doesn't provide an SMMU device parameter. Since dev_to_node
> doesn't accept a
Hi Will,
On Fri, Jun 15, 2018 at 10:22 PM, Will Deacon wrote:
> Hi Vivek,
>
> On Fri, Jun 15, 2018 at 04:23:29PM +0530, Vivek Gautam wrote:
>> Qualcomm SoCs have an additional level of cache called as
>> System cache or Last level cache[1]. This cache sits right
>> before the DDR, and is tightly
Switch to the generic noncoherent direct mapping implementation.
Fix sync_single_for_cpu to do skip the cache flush unless the transfer
is to the device to match the more tested unmap_single path which should
have the same cache coherency implications.
Signed-off-by: Christoph Hellwig
---
arch/
Current the S/G list based DMA ops use flush_kernel_vmap_range which
contains a few UP optimizations, while the rest of the DMA operations
uses flush_kernel_dcache_range. The single vs sg operations are supposed
to have the same effect, so they should use the same routines. Use
the more conservat
The only difference is that pcxl supports dma coherent allocations, while
pcx only supports non-consistent allocations and otherwise fails.
But dma_alloc* is not in the fast path, and merging these two allows an
easy migration path to the generic dma-noncoherent implementation, so
do it.
Signed-o
This should address all the comments raised last time.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/xtensa/Kconfig | 3 +
arch/xtensa/include/asm/Kbuild| 1 +
arch/xtensa/include/asm/dma-mapping.h | 26 --
arch/xtensa/kernel/pci-dma.c | 130 +++-
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/nios2/Kconfig | 3 +
arch/nios2/include/asm/Kbuild| 1 +
arch/nios2/include/asm/dma-mapping.h | 20
arch/nios2/mm/dma-mapping.c | 139 +++---
21 matches
Mail list logo
