> -----Original Message-----
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, August 04, 2017 5:57 PM
> To: Shameerali Kolothum Thodi; lorenzo.pieral...@arm.com;
> marc.zyng...@arm.com; sudeep.ho...@arm.com; will.dea...@arm.com;
> Cc: Gabriele Paoloni; John Garry; email@example.com; linux-
> arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> de...@acpica.org; Linuxarm; Wangzhou (B); Guohanjun (Hanjun Guo)
> Subject: Re: [PATCH v5 1/2] ACPI/IORT: Add ITS address regions reservation
> On 01/08/17 11:49, Shameer Kolothum wrote:
> > On some platforms ITS address regions have to be excluded from normal
> > IOVA allocation in that they are detected and decoded in a HW specific
> > way by system components and so they cannot be considered normal
> > address space.
> > Add an helper function that retrieves ITS address regions through IORT
> > device <-> ITS mappings and reserves it so that these regions will not
> > be translated by IOMMU and will be excluded from IOVA allocations.
> I've just realised that we no longer seem to have a check that ensures
> the regions are only reserved on platforms that need it - if not, then
> we're going to break everything else that does have an ITS behind SMMU
> translation as expected.
Right. I had this doubt, but then my thinking was that we will have the SW_MSI
regions for those and will end up using that. But that doesn’t seems
to be the case now.
> It feels like IORT should know enough to be able to make that decision
> internally, but if not (or if it would be hideous to do so), then I
> guess my idea for patch #2 was a bust and we probably do need to go back
> to calling directly from the SMMU driver based on the SMMU model.
It might be possible to do that check inside iort code, but then we have to find
the smmu node first and check the model number. I think it will be more
cleaner if SMMU driver makes that check and call the
If you are Ok with that I will quickly rework and send out the next version.
iommu mailing list