Re: [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Jun 02, 2026 at 09:13:39PM +0100, Will Deacon wrote:
> On Mon, Jun 01, 2026 at 10:48:44AM +0000, Ashish Mhetre wrote:
> > Tegra264 SMMU is affected by erratum where a TLB entry can survive an
> > invalidation that races with concurrent traffic targeting the same
> > entry. The hardware-recommended software workaround is to issue every
> > CFGI/TLBI command (each followed by CMD_SYNC) twice. The second issue
> > is guaranteed to evict the entry. ATC_INV is not affected and must not
> > be doubled.
> > 
> > The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
> > cannot be detected from hardware ID. Tegra264 boots from device tree
> > only and has no ACPI/IORT support, so detection is through device
> > tree only.
> 
> That seems odd to me -- whether the hardware has the erratum is
> completely unrelated to whether it probes using DT or ACPI, so I find it
> really weird to have the workaround enabled when booting with DT and not
> when booting with ACPI. We should have consistent behaviour between the
> two.

That's a good point. Yet, for ACPI to detect the erratum, we would
need a new IORT model or flag, right? That would need to go through
the entire ACPI protocol to update SMMU's IORT spec and the header
accordingly, which we don't have a use case to do so or to test it.

What would you like us to do here for the consistency?

Thanks
Nicolin