On 5/11/2020 4:34 PM, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> When ever a new iova alloc request comes iova is always searched
> from the cached node and the nodes which are previous to cached
> node. So, even if there is free iova space available in the nodes
> which are nex
The struct hyperv_ir_domain_ops is not modified and can be made const to
allow the compiler to put it in read-only memory.
Before:
textdata bss dec hex filename
29161180112052161460 drivers/iommu/hyperv-iommu.o
After:
textdata bss dec hex f
The struct sun50i_iommu_ops is not modified and can be made const to
allow the compiler to put it in read-only memory.
Before:
textdata bss dec hex filename
143582501 64 16923421b drivers/iommu/sun50i-iommu.o
After:
textdata bss dec hex filen
Constify some structs with function pointers to allow the compiler to
put them in read-only memory. There is not dependency between the
patches.
Rikard Falkeborn (2):
iommu/hyper-v: Constify hyperv_ir_domain_ops
iommu/sun50i: Constify sun50i_iommu_ops
drivers/iommu/hyperv-iommu.c | 2 +-
dri
The mapping operations of the Tegra SMMU driver are subjected to a race
condition issues because SMMU Address Space isn't allocated and freed
atomically, while it should be. This patch makes the mapping operations
atomic, it fixes an accidentally released Host1x Address Space problem
which happens
25.05.2020 15:20, Thierry Reding пишет:
...
> Do we have a good way to find out how bad exactly the contention would
> be when using a mutex?
I'm now having a second thought about it. We don't need to care about
that scenario at all because it's a software-design defect of the
upstream Host1x driv
On Thu, May 21, 2020 at 11:49:06AM -0700, Andrew Morton wrote:
> I'll assume that Joerg will handle this fix?
Yes, I will when it turns out necessary.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfo
On Thu, May 21, 2020 at 06:39:44PM +0100, Will Deacon wrote:
> Hi Joerg,
>
> Please pull these Arm SMMU updates for 5.8. The branch is based on your
> 'core' branch from a little while ago.
>
> Summary in the tag.
>
> Cheers,
>
> Will
>
> --->8
>
> The following changes since commit 1b032ec1e
On Sun, May 17, 2020 at 08:29:17AM +, Prakhya, Sai Praneeth wrote:
> iommu_bus_notifier()
> -> iommu_release_device()
> -> ops->release_device() (Eg: intel_iommu_release_device())
> -> iommu_group_remove_device()
>-> mutex_lock()
>
> But, I added print statements to iommu_bus_notifier()
On Tue, May 12, 2020 at 12:08:29PM +0800, Zhangfei Gao wrote:
> Some platform devices appear as PCI but are
> actually on the AMBA bus, and they need fixup in
> drivers/pci/quirks.c handling iommu_fwnode.
> So calling pci_fixup_final after iommu_fwnode is allocated.
>
> For example:
> Hisilicon p
Hi Joerg,
On 2020-05-25 18:31, Joerg Roedel wrote:
From: Joerg Roedel
The iommu_alloc_default_domain() function takes a reference to an IOMMU
group without releasing it. This causes the group to never be released,
with undefined side effects.
The function has only one call-site, which takes a
Hi Joerg,
On 2020-05-25 18:32, Joerg Roedel wrote:
Hi,
On Fri, May 22, 2020 at 06:31:45PM +0530, Sai Prakash Ranjan wrote:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a4c2f122eb8b..05f7b77c432f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1491,6 +1491
Hi,
On Fri, May 22, 2020 at 06:31:45PM +0530, Sai Prakash Ranjan wrote:
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index a4c2f122eb8b..05f7b77c432f 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1491,6 +1491,7 @@ static int iommu_alloc_default_domain(s
From: Joerg Roedel
The iommu_alloc_default_domain() function takes a reference to an IOMMU
group without releasing it. This causes the group to never be released,
with undefined side effects.
The function has only one call-site, which takes a group reference on
its own, so to fix this leak, do n
On Mon, May 25, 2020 at 01:51:50PM +0300, Dmitry Osipenko wrote:
> 25.05.2020 11:35, Thierry Reding пишет:
> > On Sun, May 24, 2020 at 09:37:55PM +0300, Dmitry Osipenko wrote:
> >> The mapping operations of the Tegra SMMU driver are subjected to a race
> >> condition issues because SMMU Address Spa
On Thu, May 21, 2020 at 05:50:30PM -0400, Qian Cai wrote:
> The commit 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function")
> introduced a GCC warning,
>
> drivers/iommu/intel-iommu.c:5330:1: warning: 'static' is not at beginning of
> declaration [-Wold-style-declaration]
> const static i
Hi Guillaume,
On Wed, May 20, 2020 at 10:54:44AM +0100, Guillaume Tucker wrote:
> Please see the bisection report below about a boot failure.
>
> Reports aren't automatically sent to the public while we're
> trialing new bisection features on kernelci.org but this one
> looks valid.
>
> Unfortun
[+cc Kirti, Yan, Alex]
On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
> Hi,
>
> On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:
>> Hi all,
>>
>> Is there any plan for enabling SMMU HTTU?
>
> Not outside of SVA, as far as I know.
>
>> I have seen the patch locates in the SVA serie
25.05.2020 11:35, Thierry Reding пишет:
> On Sun, May 24, 2020 at 09:37:55PM +0300, Dmitry Osipenko wrote:
>> The mapping operations of the Tegra SMMU driver are subjected to a race
>> condition issues because SMMU Address Space isn't allocated and freed
>> atomically, while it should be. This patc
On Sun, May 24, 2020 at 09:37:55PM +0300, Dmitry Osipenko wrote:
> The mapping operations of the Tegra SMMU driver are subjected to a race
> condition issues because SMMU Address Space isn't allocated and freed
> atomically, while it should be. This patch makes the mapping operations
> atomic, it f
20 matches
Mail list logo
