From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: Joerg Roedel <joro@8bytes.org>, Li Yang <leoyang.li@nxp.com>,
Michael Ellerman <mpe@ellerman.id.au>,
David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
linuxppc-dev@lists.ozlabs.org, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org
Subject: Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
Date: Tue, 30 Mar 2021 14:19:38 +0100 [thread overview]
Message-ID: <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com> (raw)
In-Reply-To: <20210330131149.GP5908@willie-the-truck>
On 2021-03-30 14:11, Will Deacon wrote:
> On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> Instead make the global iommu_dma_strict paramete in iommu.c canonical by
>> exporting helpers to get and set it and use those directly in the drivers.
>>
>> This make sure that the iommu.strict parameter also works for the AMD and
>> Intel IOMMU drivers on x86. As those default to lazy flushing a new
>> IOMMU_CMD_LINE_STRICT is used to turn the value into a tristate to
>> represent the default if not overriden by an explicit parameter.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>.
>> [ported on top of the other iommu_attr changes and added a few small
>> missing bits]
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>> drivers/iommu/amd/iommu.c | 23 +-------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 +---------------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 -
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 27 +--------
>> drivers/iommu/dma-iommu.c | 9 +--
>> drivers/iommu/intel/iommu.c | 64 ++++-----------------
>> drivers/iommu/iommu.c | 27 ++++++---
>> include/linux/iommu.h | 4 +-
>> 8 files changed, 40 insertions(+), 165 deletions(-)
>
> I really like this cleanup, but I can't help wonder if it's going in the
> wrong direction. With SoCs often having multiple IOMMU instances and a
> distinction between "trusted" and "untrusted" devices, then having the
> flush-queue enabled on a per-IOMMU or per-domain basis doesn't sound
> unreasonable to me, but this change makes it a global property.
The intent here was just to streamline the existing behaviour of
stuffing a global property into a domain attribute then pulling it out
again in the illusion that it was in any way per-domain. We're still
checking dev_is_untrusted() before making an actual decision, and it's
not like we can't add more factors at that point if we want to.
> For example, see the recent patch from Lu Baolu:
>
> https://lore.kernel.org/r/20210225061454.2864009-1-baolu.lu@linux.intel.com
Erm, this patch is based on that one, it's right there in the context :/
Thanks,
Robin.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: freedreno@lists.freedesktop.org, kvm@vger.kernel.org,
Joerg Roedel <joro@8bytes.org>,
linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
Li Yang <leoyang.li@nxp.com>,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
Date: Tue, 30 Mar 2021 14:19:38 +0100 [thread overview]
Message-ID: <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com> (raw)
In-Reply-To: <20210330131149.GP5908@willie-the-truck>
On 2021-03-30 14:11, Will Deacon wrote:
> On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> Instead make the global iommu_dma_strict paramete in iommu.c canonical by
>> exporting helpers to get and set it and use those directly in the drivers.
>>
>> This make sure that the iommu.strict parameter also works for the AMD and
>> Intel IOMMU drivers on x86. As those default to lazy flushing a new
>> IOMMU_CMD_LINE_STRICT is used to turn the value into a tristate to
>> represent the default if not overriden by an explicit parameter.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>.
>> [ported on top of the other iommu_attr changes and added a few small
>> missing bits]
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>> drivers/iommu/amd/iommu.c | 23 +-------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 +---------------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 -
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 27 +--------
>> drivers/iommu/dma-iommu.c | 9 +--
>> drivers/iommu/intel/iommu.c | 64 ++++-----------------
>> drivers/iommu/iommu.c | 27 ++++++---
>> include/linux/iommu.h | 4 +-
>> 8 files changed, 40 insertions(+), 165 deletions(-)
>
> I really like this cleanup, but I can't help wonder if it's going in the
> wrong direction. With SoCs often having multiple IOMMU instances and a
> distinction between "trusted" and "untrusted" devices, then having the
> flush-queue enabled on a per-IOMMU or per-domain basis doesn't sound
> unreasonable to me, but this change makes it a global property.
The intent here was just to streamline the existing behaviour of
stuffing a global property into a domain attribute then pulling it out
again in the illusion that it was in any way per-domain. We're still
checking dev_is_untrusted() before making an actual decision, and it's
not like we can't add more factors at that point if we want to.
> For example, see the recent patch from Lu Baolu:
>
> https://lore.kernel.org/r/20210225061454.2864009-1-baolu.lu@linux.intel.com
Erm, this patch is based on that one, it's right there in the context :/
Thanks,
Robin.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: freedreno@lists.freedesktop.org, kvm@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
Li Yang <leoyang.li@nxp.com>,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
Date: Tue, 30 Mar 2021 14:19:38 +0100 [thread overview]
Message-ID: <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com> (raw)
In-Reply-To: <20210330131149.GP5908@willie-the-truck>
On 2021-03-30 14:11, Will Deacon wrote:
> On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> Instead make the global iommu_dma_strict paramete in iommu.c canonical by
>> exporting helpers to get and set it and use those directly in the drivers.
>>
>> This make sure that the iommu.strict parameter also works for the AMD and
>> Intel IOMMU drivers on x86. As those default to lazy flushing a new
>> IOMMU_CMD_LINE_STRICT is used to turn the value into a tristate to
>> represent the default if not overriden by an explicit parameter.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>.
>> [ported on top of the other iommu_attr changes and added a few small
>> missing bits]
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>> drivers/iommu/amd/iommu.c | 23 +-------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 +---------------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 -
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 27 +--------
>> drivers/iommu/dma-iommu.c | 9 +--
>> drivers/iommu/intel/iommu.c | 64 ++++-----------------
>> drivers/iommu/iommu.c | 27 ++++++---
>> include/linux/iommu.h | 4 +-
>> 8 files changed, 40 insertions(+), 165 deletions(-)
>
> I really like this cleanup, but I can't help wonder if it's going in the
> wrong direction. With SoCs often having multiple IOMMU instances and a
> distinction between "trusted" and "untrusted" devices, then having the
> flush-queue enabled on a per-IOMMU or per-domain basis doesn't sound
> unreasonable to me, but this change makes it a global property.
The intent here was just to streamline the existing behaviour of
stuffing a global property into a domain attribute then pulling it out
again in the illusion that it was in any way per-domain. We're still
checking dev_is_untrusted() before making an actual decision, and it's
not like we can't add more factors at that point if we want to.
> For example, see the recent patch from Lu Baolu:
>
> https://lore.kernel.org/r/20210225061454.2864009-1-baolu.lu@linux.intel.com
Erm, this patch is based on that one, it's right there in the context :/
Thanks,
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: freedreno@lists.freedesktop.org, kvm@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Joerg Roedel <joro@8bytes.org>,
linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
Li Yang <leoyang.li@nxp.com>,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
Date: Tue, 30 Mar 2021 14:19:38 +0100 [thread overview]
Message-ID: <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com> (raw)
In-Reply-To: <20210330131149.GP5908@willie-the-truck>
On 2021-03-30 14:11, Will Deacon wrote:
> On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> Instead make the global iommu_dma_strict paramete in iommu.c canonical by
>> exporting helpers to get and set it and use those directly in the drivers.
>>
>> This make sure that the iommu.strict parameter also works for the AMD and
>> Intel IOMMU drivers on x86. As those default to lazy flushing a new
>> IOMMU_CMD_LINE_STRICT is used to turn the value into a tristate to
>> represent the default if not overriden by an explicit parameter.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>.
>> [ported on top of the other iommu_attr changes and added a few small
>> missing bits]
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>> drivers/iommu/amd/iommu.c | 23 +-------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 +---------------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 -
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 27 +--------
>> drivers/iommu/dma-iommu.c | 9 +--
>> drivers/iommu/intel/iommu.c | 64 ++++-----------------
>> drivers/iommu/iommu.c | 27 ++++++---
>> include/linux/iommu.h | 4 +-
>> 8 files changed, 40 insertions(+), 165 deletions(-)
>
> I really like this cleanup, but I can't help wonder if it's going in the
> wrong direction. With SoCs often having multiple IOMMU instances and a
> distinction between "trusted" and "untrusted" devices, then having the
> flush-queue enabled on a per-IOMMU or per-domain basis doesn't sound
> unreasonable to me, but this change makes it a global property.
The intent here was just to streamline the existing behaviour of
stuffing a global property into a domain attribute then pulling it out
again in the illusion that it was in any way per-domain. We're still
checking dev_is_untrusted() before making an actual decision, and it's
not like we can't add more factors at that point if we want to.
> For example, see the recent patch from Lu Baolu:
>
> https://lore.kernel.org/r/20210225061454.2864009-1-baolu.lu@linux.intel.com
Erm, this patch is based on that one, it's right there in the context :/
Thanks,
Robin.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: Joerg Roedel <joro@8bytes.org>, Li Yang <leoyang.li@nxp.com>,
Michael Ellerman <mpe@ellerman.id.au>,
David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
linuxppc-dev@lists.ozlabs.org, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org
Subject: Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
Date: Tue, 30 Mar 2021 14:19:38 +0100 [thread overview]
Message-ID: <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com> (raw)
In-Reply-To: <20210330131149.GP5908@willie-the-truck>
On 2021-03-30 14:11, Will Deacon wrote:
> On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> Instead make the global iommu_dma_strict paramete in iommu.c canonical by
>> exporting helpers to get and set it and use those directly in the drivers.
>>
>> This make sure that the iommu.strict parameter also works for the AMD and
>> Intel IOMMU drivers on x86. As those default to lazy flushing a new
>> IOMMU_CMD_LINE_STRICT is used to turn the value into a tristate to
>> represent the default if not overriden by an explicit parameter.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>.
>> [ported on top of the other iommu_attr changes and added a few small
>> missing bits]
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>> drivers/iommu/amd/iommu.c | 23 +-------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 +---------------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 -
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 27 +--------
>> drivers/iommu/dma-iommu.c | 9 +--
>> drivers/iommu/intel/iommu.c | 64 ++++-----------------
>> drivers/iommu/iommu.c | 27 ++++++---
>> include/linux/iommu.h | 4 +-
>> 8 files changed, 40 insertions(+), 165 deletions(-)
>
> I really like this cleanup, but I can't help wonder if it's going in the
> wrong direction. With SoCs often having multiple IOMMU instances and a
> distinction between "trusted" and "untrusted" devices, then having the
> flush-queue enabled on a per-IOMMU or per-domain basis doesn't sound
> unreasonable to me, but this change makes it a global property.
The intent here was just to streamline the existing behaviour of
stuffing a global property into a domain attribute then pulling it out
again in the illusion that it was in any way per-domain. We're still
checking dev_is_untrusted() before making an actual decision, and it's
not like we can't add more factors at that point if we want to.
> For example, see the recent patch from Lu Baolu:
>
> https://lore.kernel.org/r/20210225061454.2864009-1-baolu.lu@linux.intel.com
Erm, this patch is based on that one, it's right there in the context :/
Thanks,
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: freedreno@lists.freedesktop.org, kvm@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Joerg Roedel <joro@8bytes.org>,
linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
Li Yang <leoyang.li@nxp.com>,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org,
Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
Date: Tue, 30 Mar 2021 14:19:38 +0100 [thread overview]
Message-ID: <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com> (raw)
In-Reply-To: <20210330131149.GP5908@willie-the-truck>
On 2021-03-30 14:11, Will Deacon wrote:
> On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> Instead make the global iommu_dma_strict paramete in iommu.c canonical by
>> exporting helpers to get and set it and use those directly in the drivers.
>>
>> This make sure that the iommu.strict parameter also works for the AMD and
>> Intel IOMMU drivers on x86. As those default to lazy flushing a new
>> IOMMU_CMD_LINE_STRICT is used to turn the value into a tristate to
>> represent the default if not overriden by an explicit parameter.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>.
>> [ported on top of the other iommu_attr changes and added a few small
>> missing bits]
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>> drivers/iommu/amd/iommu.c | 23 +-------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 +---------------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 -
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 27 +--------
>> drivers/iommu/dma-iommu.c | 9 +--
>> drivers/iommu/intel/iommu.c | 64 ++++-----------------
>> drivers/iommu/iommu.c | 27 ++++++---
>> include/linux/iommu.h | 4 +-
>> 8 files changed, 40 insertions(+), 165 deletions(-)
>
> I really like this cleanup, but I can't help wonder if it's going in the
> wrong direction. With SoCs often having multiple IOMMU instances and a
> distinction between "trusted" and "untrusted" devices, then having the
> flush-queue enabled on a per-IOMMU or per-domain basis doesn't sound
> unreasonable to me, but this change makes it a global property.
The intent here was just to streamline the existing behaviour of
stuffing a global property into a domain attribute then pulling it out
again in the illusion that it was in any way per-domain. We're still
checking dev_is_untrusted() before making an actual decision, and it's
not like we can't add more factors at that point if we want to.
> For example, see the recent patch from Lu Baolu:
>
> https://lore.kernel.org/r/20210225061454.2864009-1-baolu.lu@linux.intel.com
Erm, this patch is based on that one, it's right there in the context :/
Thanks,
Robin.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-03-30 13:20 UTC|newest]
Thread overview: 282+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 15:38 cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver v2 Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` [PATCH 01/18] iommu: remove the unused domain_window_disable method Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:04 ` Will Deacon
2021-03-30 12:04 ` Will Deacon
2021-03-30 12:04 ` Will Deacon
2021-03-30 12:04 ` Will Deacon
2021-03-30 12:04 ` Will Deacon
2021-03-30 12:04 ` Will Deacon
2021-03-16 15:38 ` [PATCH 02/18] iommu/fsl_pamu: remove fsl_pamu_get_domain_attr Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:10 ` Will Deacon
2021-03-30 12:10 ` Will Deacon
2021-03-30 12:10 ` Will Deacon
2021-03-30 12:10 ` Will Deacon
2021-03-30 12:10 ` Will Deacon
2021-03-30 12:10 ` Will Deacon
2021-03-16 15:38 ` [PATCH 03/18] iommu/fsl_pamu: remove support for setting DOMAIN_ATTR_GEOMETRY Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:15 ` Will Deacon
2021-03-30 12:15 ` Will Deacon
2021-03-30 12:15 ` Will Deacon
2021-03-30 12:15 ` Will Deacon
2021-03-30 12:15 ` Will Deacon
2021-03-30 12:15 ` Will Deacon
2021-03-16 15:38 ` [PATCH 04/18] iommu/fsl_pamu: merge iommu_alloc_dma_domain into fsl_pamu_domain_alloc Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:17 ` Will Deacon
2021-03-30 12:17 ` Will Deacon
2021-03-30 12:17 ` Will Deacon
2021-03-30 12:17 ` Will Deacon
2021-03-30 12:17 ` Will Deacon
2021-03-30 12:17 ` Will Deacon
2021-03-16 15:38 ` [PATCH 05/18] iommu/fsl_pamu: remove support for multiple windows Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:22 ` Will Deacon
2021-03-30 12:22 ` Will Deacon
2021-03-30 12:22 ` Will Deacon
2021-03-30 12:22 ` Will Deacon
2021-03-30 12:22 ` Will Deacon
2021-03-30 12:22 ` Will Deacon
2021-04-01 9:29 ` Christoph Hellwig
2021-04-01 9:29 ` Christoph Hellwig
2021-04-01 9:29 ` Christoph Hellwig
2021-04-01 9:29 ` Christoph Hellwig
2021-04-01 9:29 ` Christoph Hellwig
2021-03-16 15:38 ` [PATCH 06/18] iommu/fsl_pamu: remove ->domain_window_enable Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:40 ` Will Deacon
2021-03-30 12:40 ` Will Deacon
2021-03-30 12:40 ` Will Deacon
2021-03-30 12:40 ` Will Deacon
2021-03-30 12:40 ` Will Deacon
2021-03-30 12:40 ` Will Deacon
2021-04-01 9:32 ` Christoph Hellwig
2021-04-01 9:32 ` Christoph Hellwig
2021-04-01 9:32 ` Christoph Hellwig
2021-04-01 9:32 ` Christoph Hellwig
2021-04-01 9:32 ` Christoph Hellwig
2021-03-16 15:38 ` [PATCH 07/18] iommu/fsl_pamu: replace DOMAIN_ATTR_FSL_PAMU_STASH with a direct call Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:44 ` Will Deacon
2021-03-30 12:44 ` Will Deacon
2021-03-30 12:44 ` Will Deacon
2021-03-30 12:44 ` Will Deacon
2021-03-30 12:44 ` Will Deacon
2021-03-30 12:44 ` Will Deacon
2021-03-16 15:38 ` [PATCH 08/18] iommu/fsl_pamu: merge pamu_set_liodn and map_liodn Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:46 ` Will Deacon
2021-03-30 12:46 ` Will Deacon
2021-03-30 12:46 ` Will Deacon
2021-03-30 12:46 ` Will Deacon
2021-03-30 12:46 ` Will Deacon
2021-03-30 12:46 ` Will Deacon
2021-04-01 9:34 ` Christoph Hellwig
2021-04-01 9:34 ` Christoph Hellwig
2021-04-01 9:34 ` Christoph Hellwig
2021-04-01 9:34 ` Christoph Hellwig
2021-04-01 9:34 ` Christoph Hellwig
2021-03-16 15:38 ` [PATCH 09/18] iommu/fsl_pamu: merge handle_attach_device into fsl_pamu_attach_device Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:48 ` Will Deacon
2021-03-30 12:48 ` Will Deacon
2021-03-30 12:48 ` Will Deacon
2021-03-30 12:48 ` Will Deacon
2021-03-30 12:48 ` Will Deacon
2021-03-30 12:48 ` Will Deacon
2021-03-16 15:38 ` [PATCH 10/18] iommu/fsl_pamu: enable the liodn when attaching a device Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:53 ` Will Deacon
2021-03-30 12:53 ` Will Deacon
2021-03-30 12:53 ` Will Deacon
2021-03-30 12:53 ` Will Deacon
2021-03-30 12:53 ` Will Deacon
2021-03-30 12:53 ` Will Deacon
2021-03-16 15:38 ` [PATCH 11/18] iommu/fsl_pamu: remove the snoop_id field Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-04-01 9:36 ` Christoph Hellwig
2021-04-01 9:36 ` Christoph Hellwig
2021-04-01 9:36 ` Christoph Hellwig
2021-04-01 9:36 ` Christoph Hellwig
2021-04-01 9:36 ` Christoph Hellwig
2021-03-16 15:38 ` [PATCH 12/18] iommu: remove DOMAIN_ATTR_PAGING Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-30 12:58 ` Will Deacon
2021-03-16 15:38 ` [PATCH 13/18] iommu: remove DOMAIN_ATTR_GEOMETRY Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 13:00 ` Will Deacon
2021-03-30 13:00 ` Will Deacon
2021-03-30 13:00 ` Will Deacon
2021-03-30 13:00 ` Will Deacon
2021-03-30 13:00 ` Will Deacon
2021-03-30 13:00 ` Will Deacon
2021-03-16 15:38 ` [PATCH 14/18] iommu: remove DOMAIN_ATTR_NESTING Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 13:04 ` Will Deacon
2021-03-30 13:04 ` Will Deacon
2021-03-30 13:04 ` Will Deacon
2021-03-30 13:04 ` Will Deacon
2021-03-30 13:04 ` Will Deacon
2021-03-30 13:04 ` Will Deacon
2021-03-16 15:38 ` [PATCH 15/18] iommu: remove iommu_set_cmd_line_dma_api and iommu_cmd_line_dma_api Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 13:05 ` Will Deacon
2021-03-30 13:05 ` Will Deacon
2021-03-30 13:05 ` Will Deacon
2021-03-30 13:05 ` Will Deacon
2021-03-30 13:05 ` Will Deacon
2021-03-30 13:05 ` Will Deacon
2021-03-16 15:38 ` [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 13:11 ` Will Deacon
2021-03-30 13:11 ` Will Deacon
2021-03-30 13:11 ` Will Deacon
2021-03-30 13:11 ` Will Deacon
2021-03-30 13:11 ` Will Deacon
2021-03-30 13:11 ` Will Deacon
2021-03-30 13:19 ` Robin Murphy [this message]
2021-03-30 13:19 ` Robin Murphy
2021-03-30 13:19 ` Robin Murphy
2021-03-30 13:19 ` Robin Murphy
2021-03-30 13:19 ` Robin Murphy
2021-03-30 13:19 ` Robin Murphy
2021-03-30 13:58 ` Will Deacon
2021-03-30 13:58 ` Will Deacon
2021-03-30 13:58 ` Will Deacon
2021-03-30 13:58 ` Will Deacon
2021-03-30 13:58 ` Will Deacon
2021-03-30 13:58 ` Will Deacon
2021-03-30 16:28 ` Robin Murphy
2021-03-30 16:28 ` Robin Murphy
2021-03-30 16:28 ` Robin Murphy
2021-03-30 16:28 ` Robin Murphy
2021-03-30 16:28 ` Robin Murphy
2021-03-30 16:28 ` Robin Murphy
2021-03-31 11:49 ` Will Deacon
2021-03-31 11:49 ` Will Deacon
2021-03-31 11:49 ` Will Deacon
2021-03-31 11:49 ` Will Deacon
2021-03-31 11:49 ` Will Deacon
2021-03-31 11:49 ` Will Deacon
2021-03-31 13:09 ` Robin Murphy
2021-03-31 13:09 ` Robin Murphy
2021-03-31 13:09 ` Robin Murphy
2021-03-31 13:09 ` Robin Murphy
2021-03-31 13:09 ` Robin Murphy
2021-03-31 13:09 ` Robin Murphy
2021-03-31 15:32 ` Will Deacon
2021-03-31 15:32 ` Will Deacon
2021-03-31 15:32 ` Will Deacon
2021-03-31 15:32 ` Will Deacon
2021-03-31 15:32 ` Will Deacon
2021-03-31 15:32 ` Will Deacon
2021-03-31 16:05 ` Robin Murphy
2021-03-31 16:05 ` Robin Murphy
2021-03-31 16:05 ` Robin Murphy
2021-03-31 16:05 ` Robin Murphy
2021-03-31 16:05 ` Robin Murphy
2021-03-31 16:05 ` Robin Murphy
2021-04-01 9:59 ` Christoph Hellwig
2021-04-01 9:59 ` Christoph Hellwig
2021-04-01 9:59 ` Christoph Hellwig
2021-04-01 9:59 ` Christoph Hellwig
2021-04-01 9:59 ` Christoph Hellwig
2021-04-01 13:26 ` Will Deacon
2021-04-01 13:26 ` Will Deacon
2021-04-01 13:26 ` Will Deacon
2021-04-01 13:26 ` Will Deacon
2021-04-01 13:26 ` Will Deacon
2021-04-01 13:26 ` Will Deacon
2021-03-31 16:07 ` Robin Murphy
2021-03-31 16:07 ` Robin Murphy
2021-03-31 16:07 ` Robin Murphy
2021-03-31 16:07 ` Robin Murphy
2021-03-31 16:07 ` Robin Murphy
2021-03-31 16:07 ` Robin Murphy
2021-03-16 15:38 ` [PATCH 17/18] iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFG Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 13:14 ` Will Deacon
2021-03-30 13:14 ` Will Deacon
2021-03-30 13:14 ` Will Deacon
2021-03-30 13:14 ` Will Deacon
2021-03-30 13:14 ` Will Deacon
2021-03-30 13:14 ` Will Deacon
2021-03-16 15:38 ` [PATCH 18/18] iommu: remove iommu_domain_{get,set}_attr Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-16 15:38 ` Christoph Hellwig
2021-03-30 13:16 ` Will Deacon
2021-03-30 13:16 ` Will Deacon
2021-03-30 13:16 ` Will Deacon
2021-03-30 13:16 ` Will Deacon
2021-03-30 13:16 ` Will Deacon
2021-03-30 13:16 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com \
--to=robin.murphy@arm.com \
--cc=baolu.lu@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dwmw2@infradead.org \
--cc=freedreno@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.