Quick reply (sorry about top post): I am just getting online so I might discover that this callback is shared by both - in which case, cool - but if not, we need an interim ACPI solution.
Aside: Current RHEL Server for ARM (RHELSA) explicitly disables SMMUv3 support because (I warned the folks involved more than a year ago), we will only support ACPI/IORT, and as you can imagine, many people would like us to enable support for device passthrough and robustness, not to mention 32-bit devices (32-bit DMA mask). Nonetheless, that will only happen when the upstream kernel has IORT and quirks in place. -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On Jun 23, 2016, at 08:04, Robin Murphy <robin.mur...@arm.com> wrote: > >> On 23/06/16 06:01, Jon Masters wrote: >>> On 05/11/2016 10:26 AM, Robin Murphy wrote: >>> (I have no actual objection to this patch, though, and at this point >>> I'm just chucking ideas about). >> >> Can I ask what the next steps are here? We're looking for upstream >> direction to guide some internal activities and could really do with >> understanding how you'd like to solve this one longer term as well as >> what interim solution could be acceptable until we get there. > > Well, for now I'm planning to leave the explicit "terminate the alias walk > from the callback function" behaviour in the DT-parsing code[1], since there > doesn't seem any good reason not to. As Bjorn says, though, it probably is > generally useful for the PCI code to have its own knowledge of exactly where > DMA can escape the PCI hierarchy - I now wonder if we could actually just do > that from the DT/IORT code; if firmware says a particular bridge/etc. has a > relationship with an ITS or SMMU, then presumably it's reasonable to infer > that DMA can come out of it, thus we could inform the PCI code there and then > without it having to quirk things on its own? > > Robin. > > [1]:http://article.gmane.org/gmane.linux.kernel.iommu/13932 > >> >> Jon. > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
