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

[Will Deacon]

On Tue, Jun 02, 2026 at 01:31:58PM -0700, Nicolin Chen wrote:
> 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?

Gah, I now realise I've mixed up Tegra264 and Tegra241 because
tegra_cmdqv_dt_probe() is only called if the compatible string matches
"nvidia,tegra264-smmu" yet all the cmdqv stuff talks only about
Tegra241. So I was surprised that the ACPI probing code for Tegra241
wasn't enabling the workaround.

But if you're saying that:

1. Tegra264 never uses ACPI
2. Tegra241 doesn't have the invalidation erratum

Then I'm less worried (even though it's a shame that we can't detect
the erratum from the hardware itself).

Will