[PATCH 1/2] dt-bindings: arm-smmu: Add qcom,last-ctx-bank-reserved
Marc Gonzalez
mgonzalez at freebox.fr
Mon Aug 19 04:37:44 PDT 2024
On 18/08/2024 17:25, Rob Herring wrote:
> On Wed, Aug 14, 2024 at 03:59:55PM +0200, Marc Gonzalez wrote:
>
>> On qcom msm8998, writing to the last context bank of lpass_q6_smmu
>> (base address 0x05100000) produces a system freeze & reboot.
>>
>> Specifically, here:
>>
>> qsmmu->bypass_cbndx = smmu->num_context_banks - 1;
>> arm_smmu_cb_write(smmu, qsmmu->bypass_cbndx, ARM_SMMU_CB_SCTLR, 0);
>>
>> and here:
>>
>> arm_smmu_write_context_bank(smmu, i);
>> arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR, ARM_SMMU_CB_FSR_FAULT);
>>
>> It is likely that FW reserves the last context bank for its own use,
>> thus a simple work-around would be: DON'T USE IT in Linux.
>>
>> Signed-off-by: Marc Gonzalez <mgonzalez at freebox.fr>
>> ---
>> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index 280b4e49f2191..f9b23aef351b0 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -204,6 +204,12 @@ properties:
>> access to SMMU configuration registers. In this case non-secure aliases of
>> secure registers have to be used during SMMU configuration.
>>
>> + qcom,last-ctx-bank-reserved:
>> + type: boolean
>> + description:
>> + FW reserves the last context bank of this SMMU for its own use.
>> + If Linux tries to use it, Linux gets nuked.
>
> How is this Qualcomm specific? Presumably any implementation could do
> this if there's no way to properly partition things. Robin?
Obviously, there is nothing Qualcomm specific about reserving
an SMMU context bank for the FW / hypervisor, other than it
appears that qcom is the first to do it; or at least the
LPASS SMMU on qcom msm8998 is the first known SMMU where such
a work-around is required.
What is the correct nomenclature?
Can we just drop the vendor prefix if a property is generic
across vendors? But does it require a subsystem prefix like
"iommu" in order to not clash with generic props in other subsystems?
> Also, this property isn't very flexible. What happens when it is not the
> last bank or more than 1 bank reserved? This should probably be a mask
> instead.
OK, I'm getting conflicting requests here.
Bjorn has recommended dropping the property altogether:
> It also seems, as the different SMMUs in this platform behave
> differently it might be worth giving them further specific compatibles,
> in which case we could just check if it's the qcom,msm8998-lpass-smmu,
> instead of inventing a property for this quirk.
I'll send a patch series in line with Bjorn's request.
Regards
More information about the linux-arm-kernel
mailing list