Some platforms support more than 128 stream matching groups than what is
defined by the ARM SMMU architecture specification. But due to some unknown
reasons, those additional groups don't exhibit the same behavior as the
architecture supported ones.
For instance, the additional groups will not detect the quirky behavior of
some firmware versions intercepting writes to S2CR register, thus skipping
the quirk implemented in the driver and causing boot crash.
So let's limit the groups to 128 for now until the issue with those groups
are fixed and issue a notice to users in that case.
Reviewed-by: Johan Hovold <[email protected]>
Tested-by: Johan Hovold <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
---
Changes in v5:
* Reworded the commit message and comment to reflect the fact that the
hardware indeed supports more than 128 groups.
* Collected tags
Changes in v4:
* Spun off the SMR limiting part into a separate patch
* Dropped the quirk rework part as it is not really needed for now
Changes in v3:
* Limited num_mapping_groups to 128 as per ARM SMMU spec and removed the
check for 128 groups in qcom_smmu_bypass_quirk()
* Reworded the commit message accordingly
Changes in v2:
* Limited the check to 128 groups as per ARM SMMU spec's NUMSMRG range
* Moved the quirk handling to its own function
* Collected review tag from Bjorn
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d1b296b95c86..decf63b8c97c 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -268,12 +268,26 @@ static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain,
static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
{
- unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 1);
struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+ unsigned int last_s2cr;
u32 reg;
u32 smr;
int i;
+ /*
+ * Some platforms support more than 128 stream matching groups than
+ * what is defined by the ARM SMMU architecture specification. But due
+ * to some unknown reasons, those additional groups don't exhibit the
+ * same behavior as the architecture supported ones. So limit the groups
+ * to 128 until the behavior is fixed for the other groups.
+ */
+ if (smmu->num_mapping_groups > 128) {
+ dev_notice(smmu->dev, "\tLimiting the stream matching groups to 128\n");
+ smmu->num_mapping_groups = 128;
+ }
+
+ last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 1);
+
/*
* With some firmware versions writes to S2CR of type FAULT are
* ignored, and writing BYPASS will end up written as FAULT in the
--
2.25.1
On Mon, 27 Mar 2023 13:30:29 +0530, Manivannan Sadhasivam wrote:
> Some platforms support more than 128 stream matching groups than what is
> defined by the ARM SMMU architecture specification. But due to some unknown
> reasons, those additional groups don't exhibit the same behavior as the
> architecture supported ones.
>
> For instance, the additional groups will not detect the quirky behavior of
> some firmware versions intercepting writes to S2CR register, thus skipping
> the quirk implemented in the driver and causing boot crash.
>
> [...]
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/arm-smmu-qcom: Limit the SMR groups to 128
https://git.kernel.org/will/c/122611347326
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
On Mon, Mar 27, 2023 at 01:52:01PM +0100, Will Deacon wrote:
> On Mon, 27 Mar 2023 13:30:29 +0530, Manivannan Sadhasivam wrote:
> > Some platforms support more than 128 stream matching groups than what is
> > defined by the ARM SMMU architecture specification. But due to some unknown
> > reasons, those additional groups don't exhibit the same behavior as the
> > architecture supported ones.
> >
> > For instance, the additional groups will not detect the quirky behavior of
> > some firmware versions intercepting writes to S2CR register, thus skipping
> > the quirk implemented in the driver and causing boot crash.
> >
> > [...]
>
> Applied to will (for-joerg/arm-smmu/updates), thanks!
>
Thanks Will! Could you please tag this patch for 6.3-rcS? Even though this patch
is not fixing any issue introduced in 6.3, the affected platform (SC8280XP) has
reasonable upstream support in 6.3 and the distro folks would like to stick to
it for some time. This patch will allow them to boot mainline without any
additional out-of-tree patches.
- Mani
> [1/1] iommu/arm-smmu-qcom: Limit the SMR groups to 128
> https://git.kernel.org/will/c/122611347326
>
> Cheers,
> --
> Will
>
> https://fixes.arm64.dev
> https://next.arm64.dev
> https://will.arm64.dev
--
மணிவண்ணன் சதாசிவம்
On Thu, Mar 30, 2023 at 11:11:27AM +0530, Manivannan Sadhasivam wrote:
> On Mon, Mar 27, 2023 at 01:52:01PM +0100, Will Deacon wrote:
> > On Mon, 27 Mar 2023 13:30:29 +0530, Manivannan Sadhasivam wrote:
> > > Some platforms support more than 128 stream matching groups than what is
> > > defined by the ARM SMMU architecture specification. But due to some unknown
> > > reasons, those additional groups don't exhibit the same behavior as the
> > > architecture supported ones.
> > >
> > > For instance, the additional groups will not detect the quirky behavior of
> > > some firmware versions intercepting writes to S2CR register, thus skipping
> > > the quirk implemented in the driver and causing boot crash.
> > >
> > > [...]
> >
> > Applied to will (for-joerg/arm-smmu/updates), thanks!
> >
>
> Thanks Will! Could you please tag this patch for 6.3-rcS? Even though this patch
> is not fixing any issue introduced in 6.3, the affected platform (SC8280XP) has
> reasonable upstream support in 6.3 and the distro folks would like to stick to
> it for some time. This patch will allow them to boot mainline without any
> additional out-of-tree patches.
I already queued this up for 6.4 since it's neither a regression
nor marked for stable inclusion.
Having said that, once it lands in mainline feel free to propose a
-stable backport if it's needed by distros.
Will