arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
,dma_ops should be cleared in the teardown path. Currently, only the
device's iommu mapping structures are cleared in arch_teardown_dma_ops,
but not the dma_ops. So on the next reprobe, dma_ops left in place is
stale from the first I
On 25/05/17 18:33, Rob Clark wrote:
> 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 Documentation/devicetree
On 25/05/17 18:33, Rob Clark wrote:
> An iommu driver for Qualcomm "B" family devices which do not completely
> implement the ARM SMMU spec. These devices have context-bank register
> layout that is similar to ARM SMMU, but no global register space (or at
> least not one that is accessible).
I st
Hi Russell,
On Thursday 25 May 2017 16:05:41 Russell King - ARM Linux wrote:
> On Wed, May 24, 2017 at 02:26:13PM +0300, Laurent Pinchart wrote:
> > Again, the patch I propose is the simplest v4.12-rc fix I can think of,
> > short of reverting your complete IOMMU probe deferral patch series. Let's
Hi Sricharan,
Thank you for the patch.
On Friday 26 May 2017 16:13:37 Sricharan R wrote:
> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
> ,dma_ops should be cleared in the teardown path. Currently, only the
> device's iommu mapping structures are cleared in arch_teardown_dma_
Hi Laurent,
On 5/26/2017 7:44 PM, Laurent Pinchart wrote:
> Hi Sricharan,
>
> Thank you for the patch.
>
> On Friday 26 May 2017 16:13:37 Sricharan R wrote:
>> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
>> ,dma_ops should be cleared in the teardown path. Currently, only th
On 5/26/2017 12:04 AM, Xunlei Pang wrote:
On 05/26/2017 at 10:49 AM, Dave Young wrote:
Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.
On 05/18/17 at 07:01pm, Borislav Petkov wrote:
On Tue, Apr 18, 20
On 5/18/2017 2:50 PM, Matt Fleming wrote:
On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
+ paddr = boot_params.efi_info.efi_memmap_hi;
+ paddr <<= 32;
+ paddr |= boot_params.efi_info.
On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote:
> I guess I could do that, but this will probably only end up clearing a
> single PGD entry anyway since it's highly doubtful the address range
> would cross a 512GB boundary.
Or you can compute how many 512G-covering, i.e., PGD entries
On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote:
> In addition to the same issue as efi.memmap.phys_map, efi_phys has
> the __initdata attribute so it will be released/freed which will cause
> problems in checks performed afterwards.
Sounds to me like we should drop the __initdata att
On Fri, May 26, 2017 at 7:33 AM, Robin Murphy wrote:
> On 25/05/17 18:33, Rob Clark wrote:
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Rob Clark
>> Reviewed-by: Rob Herring
>> ---
>> .../devicetree/bindings/iommu/qcom,iommu.txt | 121
>> +
>> 1 file changed, 1
Unlike the old allocator, alloc_iova_fast() will return 0 if it failed
to allocate a PFN. Since the callers of dma_ops_alloc_iova() would end
up treating that as a valid address, translate it to the DMA_ERROR_CODE
that they would expect.
Fixes: 256e4621c21a ("iommu/amd: Make use of the generic IOV
On Fri, May 26, 2017 at 8:56 AM, Robin Murphy wrote:
> On 25/05/17 18:33, Rob Clark wrote:
>> An iommu driver for Qualcomm "B" family devices which do not completely
>> implement the ARM SMMU spec. These devices have context-bank register
>> layout that is similar to ARM SMMU, but no global regis
On 05/26/17 at 12:17pm, Xunlei Pang wrote:
> On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> > Provide support so that kexec can be used to boot a kernel when SME is
> > enabled.
> >
> > Support is needed to allocate pages for kexec without encryption. This
> > is needed in order to be able to re
14 matches
Mail list logo
