[PATCH 2/6] iommu/qcom: Write TCR before TTBRs to fix ASID access behavior

AngeloGioacchino Del Regno angelogioacchino.delregno at collabora.com
Wed Jun 8 03:27:31 PDT 2022


Il 06/06/22 00:06, Marijn Suijten ha scritto:
> On 2022-05-31 16:55:59, Will Deacon wrote:
>> On Fri, May 27, 2022 at 11:28:57PM +0200, Konrad Dybcio wrote:
>>> From: AngeloGioacchino Del Regno <angelogioacchino.delregno at somainline.org>
>>>
>>> As also stated in the arm-smmu driver, we must write the TCR before
>>> writing the TTBRs, since the TCR determines the access behavior of
>>> some fields.
>>
>> Where is this stated in the arm-smmu driver?
>>
>>>
>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at somainline.org>
>>> Signed-off-by: Marijn Suijten <marijn.suijten at somainline.org>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio at somainline.org>
>>> ---
>>>   drivers/iommu/arm/arm-smmu/qcom_iommu.c | 12 ++++++------
>>>   1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
>>> index 1728d4d7fe25..75f353866c40 100644
>>> --- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
>>> +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
>>> @@ -273,18 +273,18 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
>>>   			ctx->secure_init = true;
>>>   		}
>>>   
>>> -		/* TTBRs */
>>> -		iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
>>> -				pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
>>> -				FIELD_PREP(ARM_SMMU_TTBRn_ASID, ctx->asid));
>>> -		iommu_writeq(ctx, ARM_SMMU_CB_TTBR1, 0);
>>> -
>>>   		/* TCR */
>>>   		iommu_writel(ctx, ARM_SMMU_CB_TCR2,
>>>   				arm_smmu_lpae_tcr2(&pgtbl_cfg));
>>>   		iommu_writel(ctx, ARM_SMMU_CB_TCR,
>>>   			     arm_smmu_lpae_tcr(&pgtbl_cfg) | ARM_SMMU_TCR_EAE);
>>>   
>>> +		/* TTBRs */
>>> +		iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
>>> +				pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
>>> +				FIELD_PREP(ARM_SMMU_TTBRn_ASID, ctx->asid));
>>> +		iommu_writeq(ctx, ARM_SMMU_CB_TTBR1, 0);
>>
>> I'd have thought that SCTLR.M would be clear here, so it shouldn't matter
>> what order we write these in.
> 
> Having tested the series without this particular patch on 8976 (Sony
> Loire Suzu), it doesn't seem to matter indeed.  I'll ask around if this
> "access behaviour" was observed on a different board/platform.
> 
> - Marijn

On some platforms, the bootloader (and/or the hypervisor) is performing some
initialization of the IOMMU which, depending on the actual firmware version
that ran before booting Linux, may or may not leave SCTLR.M cleared.

Cheers,
Angelo



More information about the linux-arm-kernel mailing list