| Message ID | 20231219-topic-8280_smmuv3-v2-1-c67bd3226687@linaro.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Describe SC8280XP PCIe SMMU | expand |
On 09/03/2024 14:31, Konrad Dybcio wrote: > The smmu-v3 binding currently doesn't differentiate the SoCs it's > implemented on. This is a poor design choice that may bite in the future, > should any quirks surface. > > Add a compatible for the instance found on Qualcomm SC8280XP. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > index 75fcf4cb52d9..f284f7b0c1d8 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > @@ -20,7 +20,11 @@ properties: > $nodename: > pattern: "^iommu@[0-9a-f]*" > compatible: > - const: arm,smmu-v3 > + oneOf: > + - items: > + - const: qcom,sc8280xp-smmu-v3 This could be enum, because likely it will grow in the future, but there is no need to resend for this alone. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On 2024-03-09 1:31 pm, Konrad Dybcio wrote: > The smmu-v3 binding currently doesn't differentiate the SoCs it's > implemented on. This is a poor design choice that may bite in the future, > should any quirks surface. That doesn't seem entirely fair to say - the vast majority of bindings don't have separate compatibles for every known integration of the same implementation in different SoCs. And in this case we don't have per-implementation compatibles for quirks and errata because the implementation is architecturally discoverable from the SMMU_IIDR register. We have the whole mess for QCom SMMUv2 because the effective *implementation* is a mix of hardware and hypervisor, whose behaviour does seem to vary on almost a per-SoC basis. I'm not at all keen to start repeating that here without very good reason, and that of "documenting" a device which we typically expect to not even be accessible isn't really convincing me... Thanks, Robin. > > Add a compatible for the instance found on Qualcomm SC8280XP. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > index 75fcf4cb52d9..f284f7b0c1d8 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > @@ -20,7 +20,11 @@ properties: > $nodename: > pattern: "^iommu@[0-9a-f]*" > compatible: > - const: arm,smmu-v3 > + oneOf: > + - items: > + - const: qcom,sc8280xp-smmu-v3 > + - const: arm,smmu-v3 > + - const: arm,smmu-v3 > > reg: > maxItems: 1 >
On 19.03.2024 2:53 PM, Robin Murphy wrote: > On 2024-03-09 1:31 pm, Konrad Dybcio wrote: >> The smmu-v3 binding currently doesn't differentiate the SoCs it's >> implemented on. This is a poor design choice that may bite in the future, >> should any quirks surface. > > That doesn't seem entirely fair to say - the vast majority of bindings don't have separate compatibles for every known integration of the same implementation in different SoCs. And in this case we don't have per-implementation compatibles for quirks and errata because the implementation is architecturally discoverable from the SMMU_IIDR register. > > We have the whole mess for QCom SMMUv2 because the effective *implementation* is a mix of hardware and hypervisor, whose behaviour does seem to vary on almost a per-SoC basis. I'm not at all keen to start repeating that here without very good reason, and that of "documenting" a device which we typically expect to not even be accessible isn't really convincing me... From my POV as an arch dts maintainer, this often ends up being the only way to retroactively add some conditional action into the code - the kernel is supposed to be backwards compatible with older device trees. And so far it's been almost by luck that all of the smmuv3 implementations have been a straight copy-and-paste of the reference design (or close enough), I don't believe this will be for much longer. Konrad
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml index 75fcf4cb52d9..f284f7b0c1d8 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml @@ -20,7 +20,11 @@ properties: $nodename: pattern: "^iommu@[0-9a-f]*" compatible: - const: arm,smmu-v3 + oneOf: + - items: + - const: qcom,sc8280xp-smmu-v3 + - const: arm,smmu-v3 + - const: arm,smmu-v3 reg: maxItems: 1
The smmu-v3 binding currently doesn't differentiate the SoCs it's implemented on. This is a poor design choice that may bite in the future, should any quirks surface. Add a compatible for the instance found on Qualcomm SC8280XP. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> --- Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)