]> 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>
Thu, 18 Dec 2025 13:03:18 +0000 (14:03 +0100)
commitcefb67ea27f95715a1e33e0e9ca0488f6495e051
tree034ea6e79d144960d761b9c3931173c30465bf2d
parent57c6cea2073c4561487967476bd9c05a4d4e49e7
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