devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Johan Hovold <johan@kernel.org>
Cc: "Johan Hovold" <johan+linaro@kernel.org>,
	"Stanimir Varbanov" <svarbanov@mm-sol.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Andy Gross" <agross@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@somainline.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Krishna chaitanya chundru" <quic_krichai@quicinc.com>,
	quic_vbadigan@quicinc.com, linux-arm-msm@vger.kernel.org,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: PCI: qcom: Add SC8280XP/SA8540P interconnects
Date: Thu, 20 Oct 2022 08:29:02 -0400	[thread overview]
Message-ID: <972db8bd-e45a-47b1-c2c4-008c279c6b59@linaro.org> (raw)
In-Reply-To: <Y1D/Vaa/3zKP4Cxj@hovoldconsulting.com>

On 20/10/2022 03:57, Johan Hovold wrote:
> On Wed, Oct 19, 2022 at 10:37:31AM -0400, Krzysztof Kozlowski wrote:
>> On 17/10/2022 07:24, Johan Hovold wrote:
>>> Add the missing SC8280XP/SA8540P "pcie-mem" and "cpu-pcie" interconnect
>>> paths to the bindings.
>>>
>>> Fixes: 76d777ae045e ("dt-bindings: PCI: qcom: Add SC8280XP to binding")
>>> Fixes: 76c4207f4085 ("dt-bindings: PCI: qcom: Add SA8540P to binding")
>>> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
>>> ---
>>>  .../devicetree/bindings/pci/qcom,pcie.yaml    | 25 +++++++++++++++++++
>>>  1 file changed, 25 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>>> index 22a2aac4c23f..a55434f95edd 100644
>>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
>>> @@ -62,6 +62,12 @@ properties:
>>>      minItems: 3
>>>      maxItems: 12
>>>  
>>> +  interconnects:
>>> +    maxItems: 2
>>> +
>>> +  interconnect-names:
>>> +    maxItems: 2
>>> +
>>>    resets:
>>>      minItems: 1
>>>      maxItems: 12
>>> @@ -629,6 +635,25 @@ allOf:
>>>            items:
>>>              - const: pci # PCIe core reset
>>>  
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - qcom,pcie-sa8540p
>>> +              - qcom,pcie-sc8280xp
>>> +    then:
>>> +      properties:
>>> +        interconnects:
>>> +          maxItems: 2
>>
>> No need for this.
>>
>>> +        interconnect-names:
>>> +          items:
>>> +            - const: pcie-mem
>>> +            - const: cpu-pcie
>>> +      required:
>>> +        - interconnects
>>> +        - interconnect-names
>>
>> else:
>>   ??
>>
>> Otherwise, you allow any names for other variants.
> 
> Are you suggesting something like moving the names to the common
> constraints for now:
> 
>   interconnects:
>     maxItems: 2
> 
>   interconnect-names:
>     items:
>       - const: pcie-mem
>       - const: cpu-pcie
> 
> and then in the allOf:
> 
>   - if:
>       properties:
>         compatible:
>           contains:
>             enum:
>               - qcom,pcie-sa8540p
>               - qcom,pcie-sc8280xp
>     then:
>       required:
>         - interconnects
>         - interconnect-names
>     else:
>       properties:
>         interconnects: false
>         interconnect-names: false
> 
> This way we'd catch anyone adding interconnects to a DTS without first
> updating the bindings, but it also seems to go against the idea of
> bindings fully describing the hardware by saying that no other platforms
> have interconnects (when they actually do even if we don't describe it
> just yet).

You can add a comment to the else like "TODO: Not described yet". I
would prefer to have specific but incomplete bindings, instead of loose
one which later might cause people adding whatever names they like.

> Or should we do the above but without the else clause to have some
> constraints in place on the names at least?

This would work as well if you think the names are applicable for other
devices.

Best regards,
Krzysztof


  reply	other threads:[~2022-10-20 12:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-17 11:24 [PATCH 0/2] PCI: qcom: Add basic interconnect support Johan Hovold
2022-10-17 11:24 ` [PATCH 1/2] dt-bindings: PCI: qcom: Add SC8280XP/SA8540P interconnects Johan Hovold
2022-10-19 14:37   ` Krzysztof Kozlowski
2022-10-20  7:57     ` Johan Hovold
2022-10-20 12:29       ` Krzysztof Kozlowski [this message]
2022-10-21  6:40         ` Johan Hovold
2022-10-17 11:24 ` [PATCH 2/2] PCI: qcom: Add basic interconnect support Johan Hovold
2022-10-19 14:32   ` Brian Masney
2022-10-19 14:45     ` Johan Hovold
2022-10-20 16:49   ` Brian Masney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=972db8bd-e45a-47b1-c2c4-008c279c6b59@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=johan+linaro@kernel.org \
    --cc=johan@kernel.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=quic_krichai@quicinc.com \
    --cc=quic_vbadigan@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=svarbanov@mm-sol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).