Where a device driver has set a 64-bit DMA mask to indicate the absence
of addressing limitations, we still need to ensure that we don't
allocate IOVAs beyond the actual input size of the IOMMU. The reported
aperture is the most reliable way we have of inferring that input
address size, so use that
On 09/08/16 16:36, Joerg Roedel wrote:
> On Tue, Aug 09, 2016 at 04:23:18PM +0100, Robin Murphy wrote:
>> Where a device driver has set a 64-bit DMA mask to indicate the absence
>> of addressing limitations, we still need to ensure that we don't
>> allocate IOVAs beyond the actual input size of the
On Tue, Aug 09, 2016 at 04:23:18PM +0100, Robin Murphy wrote:
> Where a device driver has set a 64-bit DMA mask to indicate the absence
> of addressing limitations, we still need to ensure that we don't
> allocate IOVAs beyond the actual input size of the IOMMU. The reported
> aperture is the most
On Tue, Aug 09, 2016 at 04:23:17PM +0100, Robin Murphy wrote:
> Due to the limitations of having to wait until we see a device's DMA
> restrictions before we know how we want an IOVA domain initialised,
> there is a window for error if a DMA ops domain is allocated but later
> freed without ever be
On Mon, Aug 01, 2016 at 11:48:38AM +0530, Amitoj Kaur Chawla wrote:
> of_platform_device_create returns NULL on error so an IS_ERR test is
> incorrect here and a NULL check is required.
>
> The Coccinelle semantic patch used to make this change is as follows:
> @@
> expression e;
> @@
>
> e = o
Where a device driver has set a 64-bit DMA mask to indicate the absence
of addressing limitations, we still need to ensure that we don't
allocate IOVAs beyond the actual input size of the IOMMU. The reported
aperture is the most reliable way we have of inferring that input
address size, so use that
Due to the limitations of having to wait until we see a device's DMA
restrictions before we know how we want an IOVA domain initialised,
there is a window for error if a DMA ops domain is allocated but later
freed without ever being used. In that case, init_iova_domain() was
never called, so callin
On 09/08/16 16:01, Joerg Roedel wrote:
> On Wed, Jul 27, 2016 at 04:46:06PM +0100, Robin Murphy wrote:
>> Due to the limitations of having to wait until we see a device's DMA
>> restrictions before we know how we want an IOVA domain initialised,
>> there is a window for error if a DMA ops domain is
On Thu, Jul 28, 2016 at 02:10:26AM +, Wei Yongjun wrote:
> Fix to return a negative error code from the alloc_irq_index() error
> handling case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Applied, thanks.
___
i
On Thu, Jul 28, 2016 at 02:09:53AM +, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/iommu/amd_iommu.c:106:1: warning:
> symbol '__pcpu_scope_flush_queue' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun
Applied, thanks.
__
On Wed, Jul 27, 2016 at 04:46:06PM +0100, Robin Murphy wrote:
> Due to the limitations of having to wait until we see a device's DMA
> restrictions before we know how we want an IOVA domain initialised,
> there is a window for error if a DMA ops domain is allocated but later
> freed without ever be
From: Joerg Roedel
This was an oversight while merging these functions. Fix it.
Cc: Honghui Zhang
Fixes: 9ca340c98c0d ('iommu/mediatek: move the common struct into header file')
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(
On Tuesday 09 Aug 2016 16:17:57 Laurent Pinchart wrote:
> On Wednesday 08 Jun 2016 18:12:31 Magnus Damm wrote:
> > On Wed, Jun 8, 2016 at 5:48 PM, Laurent Pinchart wrote:
> >> On Wednesday 08 Jun 2016 09:04:17 Geert Uytterhoeven wrote:
> >>> On Wed, Jun 8, 2016 at 2:18 AM, Laurent Pinchart wrote:
>
Hi Magnus,
On Wednesday 08 Jun 2016 18:12:31 Magnus Damm wrote:
> On Wed, Jun 8, 2016 at 5:48 PM, Laurent Pinchart wrote:
> > On Wednesday 08 Jun 2016 09:04:17 Geert Uytterhoeven wrote:
> >> On Wed, Jun 8, 2016 at 2:18 AM, Laurent Pinchart wrote:
> --- 0031/drivers/iommu/ipmmu-vmsa.c
> +
On Tue, 2 Aug 2016, Eric Auger wrote:
> Currently the MSI message is composed by directly calling
> irq_chip_compose_msi_msg and erased by setting the memory to zero.
>
> On some platforms, we will need to complexify this composition to
> properly handle MSI emission through IOMMU. Also we will n
15 matches
Mail list logo
