On 11/04/2024 20:00, mr.nuke.me@xxxxxxxxx wrote: > > > On 4/9/24 15:08, Krzysztof Kozlowski wrote: >> On 09/04/2024 21:08, Alexandru Gagniuc wrote: >>> IPQ9574 has PCIe controllers which are almost identical to IPQ6018. >>> The only difference is that the "iface" clock is not required. >>> Document this difference along with the compatible string. >>> >>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@xxxxxxxxx> >>> --- >>> .../devicetree/bindings/pci/qcom,pcie.yaml | 34 +++++++++++++++++++ >>> 1 file changed, 34 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml >>> index cf9a6910b542..1915bea580d3 100644 >>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml >>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml >>> @@ -26,6 +26,7 @@ properties: >>> - qcom,pcie-ipq8064-v2 >>> - qcom,pcie-ipq8074 >>> - qcom,pcie-ipq8074-gen3 >>> + - qcom,pcie-ipq9574 >>> - qcom,pcie-msm8996 >>> - qcom,pcie-qcs404 >>> - qcom,pcie-sdm845 >>> @@ -397,6 +398,37 @@ allOf: >>> - const: axi_m_sticky # AXI Master Sticky reset >>> - const: axi_s_sticky # AXI Slave Sticky reset >>> >> >> Where do you constrain the reg? > > I didn't realize that was also required -- the make checks should have > picked this up too? I might be invoking the tests incorrectly. > > I should add the ipq9574 in the same list as ipq8074-gen3 and ipq6018, > correct? If you add new variant, look at existing compatibles where they appear. If there is a if: constraining compatibles, then it's a hint you should do the same for your device. So yes, you must constrain all properties which are made flexible in top-level properties. Best regards, Krzysztof
