Thread (2 messages) 2 messages, 2 authors, 2017-03-28

[PATCH V9 00/11] IOMMU probe deferral support

From: Shameerali Kolothum Thodi <hidden>
Date: 2017-03-28 14:15:56
Also in: linux-acpi, linux-arm-msm, linux-iommu, linux-pci

-----Original Message-----
From: Sricharan R [mailto:sricharan at codeaurora.org]
Sent: Tuesday, March 28, 2017 5:54 AM
To: Robin Murphy; Shameerali Kolothum Thodi; Wangzhou (B);
will.deacon at arm.com; joro at 8bytes.org; lorenzo.pieralisi at arm.com;
iommu at lists.linux-foundation.org; linux-arm-kernel at lists.infradead.org;
linux-arm-msm at vger.kernel.org; m.szyprowski at samsung.com;
bhelgaas at google.com; linux-pci at vger.kernel.org; linux-
acpi at vger.kernel.org; tn at semihalf.com; hanjun.guo at linaro.org;
okaya at codeaurora.org
Subject: Re: [PATCH V9 00/11] IOMMU probe deferral support

Hi,
[...]
quoted
quoted
quoted
 From the logs its clear that  when ixgbevf driver originally probes
and adds the device  to smmu  the dma mask is 32, but when it binds
to vfio-pci, it becomes 64 bit.
Just to add to that, the mask is set to 64 bit in the ixgebvf driver
probe[1]
Aha, but of course it's still the same struct device getting bound to
VFIO later, so whatever mask the first driver set is still in there
when we go through of_dma_configure() the second time (and the fact
that we go through more than once being the new behaviour). So yes,
this is a legitimate problem and we really do need to be robust
against size overflow. I reckon the below tweak of your fix is
probably the way to go; cleaning up the arch_setup_dma_ops() interface
can happen later.
quoted
ok, i will add this fix separately and also the acpi fix that lorenzo has
suggested in patch #8 in to the series after testing confirmation.
I can confirm that the patches fixes the issues reported here . Both 
DT and ACPI works now.
 
Cheers,
Shameer 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help