Re: [RFC v1 7/7] iommu/arm-smmu-v3: Enable ACPI based HiSilicon erratum 161010801

[John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>]

On 16/05/2017 15:03, Shameerali Kolothum Thodi wrote:
>> > Lorenzo made a point that it might be relatively straightforward to just
>> > follow the IORT mapping for the SMMU through to the ITS MADT entry and
>> > pull the ITS geometry out of that. It would certainly be nicer to have
>> > such a helper abstracted away in the IORT code than have to go parsing
>> > vendor-specific tables directly in the SMMU driver. I reckon it might be
>> > worth taking that idea a bit further to see how it looks.
> Ok. John has already mentioned this idea in our off-list discussion and we
> have one implementation where we go through the IORT node ID mappings
> array to find out the associated IORT ITS  node. It then iterates over the ACPI
> MADT  GIC ITS table entries, , looking for a match for the GIC ITS id, and
> retrieves the base address of the matching ITS.
>
> But as you said, it requires some helper from the IORT code , otherwise we
> will end up adding all the ACPI table parse code in SMMUv3. We will take
> another look at this.
>
> Thanks,
> Shameer
>

It could also be worth considering hard-coding the reserved address in 
the SMMUv3 driver for this model. This would not involve (more) reliance 
on CSRT or IORT driver. However, note that hip07 has multiple SMMUs, and 
we only need to enable the quirk for the SMMU in front the PCIe host 
controller.

John

BTW, FYI, hi161x is alias for hip07/06


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html