]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal
authorStephan Gerhold <stephan.gerhold@linaro.org>
Thu, 21 Aug 2025 08:33:53 +0000 (10:33 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 19 Jan 2026 12:09:33 +0000 (13:09 +0100)
commit5c494997d09e95cb48890d0675894e10cad58728
tree24a6e6f5540e8c53ace4b61fd088b9d1bbdf3d0b
parent342b2c26e5acfce0c4d8e3248eea5bd38ed11e30
iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal

[ Upstream commit 5583a55e074b33ccd88ac0542fd7cd656a7e2c8c ]

Some platforms (e.g. SC8280XP and X1E) support more than 128 stream
matching groups. This is more than what is defined as maximum by the ARM
SMMU architecture specification. Commit 122611347326 ("iommu/arm-smmu-qcom:
Limit the SMR groups to 128") disabled use of the additional groups because
they don't exhibit the same behavior as the architecture supported ones.

It seems like this is just another quirk of the hypervisor: When running
bare-metal without the hypervisor, the additional groups appear to behave
just like all others. The boot firmware uses some of the additional groups,
so ignoring them in this situation leads to stream match conflicts whenever
we allocate a new SMR group for the same SID.

The workaround exists primarily because the bypass quirk detection fails
when using a S2CR register from the additional matching groups, so let's
perform the test with the last reliable S2CR (127) and then limit the
number of SMR groups only if we detect that we are running below the
hypervisor (because of the bypass quirk).

Fixes: 122611347326 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c