Re: [PATCH v2 1/7] dt-bindings: interconnect: qcom: Introduce qcom,rpm-common

[Konrad Dybcio]

On 11.08.2023 18:48, Rob Herring wrote:
> On Mon, Jul 24, 2023 at 04:06:27PM +0200, Konrad Dybcio wrote:
>> The current RPM interconnect bindings are messy. Start cleaning them
>> up with a common include.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
>> ---
>>  .../bindings/interconnect/qcom,qcm2290.yaml        | 18 +++++++-------
>>  .../bindings/interconnect/qcom,rpm-common.yaml     | 28 ++++++++++++++++++++++
>>  2 files changed, 36 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
>> index f65a2fe846de..df89f390a9b0 100644
>> --- a/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
>> @@ -13,6 +13,9 @@ description: |
>>    The Qualcomm QCM2290 interconnect providers support adjusting the
>>    bandwidth requirements between the various NoC fabrics.
>>  
>> +allOf:
>> +  - $ref: qcom,rpm-common.yaml#
>> +
>>  properties:
>>    reg:
>>      maxItems: 1
>> @@ -23,9 +26,6 @@ properties:
>>        - qcom,qcm2290-cnoc
>>        - qcom,qcm2290-snoc
>>  
>> -  '#interconnect-cells':
>> -    const: 1
>> -
>>    clock-names:
>>      items:
>>        - const: bus
>> @@ -44,6 +44,9 @@ patternProperties:
>>        The interconnect providers do not have a separate QoS register space,
>>        but share parent's space.
>>  
>> +    allOf:
>> +      - $ref: qcom,rpm-common.yaml#
>> +
>>      properties:
>>        compatible:
>>          enum:
>> @@ -51,9 +54,6 @@ patternProperties:
>>            - qcom,qcm2290-mmrt-virt
>>            - qcom,qcm2290-mmnrt-virt
>>  
>> -      '#interconnect-cells':
>> -        const: 1
>> -
>>        clock-names:
>>          items:
>>            - const: bus
>> @@ -66,20 +66,18 @@ patternProperties:
>>  
>>      required:
>>        - compatible
>> -      - '#interconnect-cells'
>>        - clock-names
>>        - clocks
>>  
>> -    additionalProperties: false
>> +    unevaluatedProperties: false
>>  
>>  required:
>>    - compatible
>>    - reg
>> -  - '#interconnect-cells'
>>    - clock-names
>>    - clocks
>>  
>> -additionalProperties: false
>> +unevaluatedProperties: false
>>  
>>  examples:
>>    - |
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml
>> new file mode 100644
>> index 000000000000..1ea52b091609
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml
>> @@ -0,0 +1,28 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpm-common.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm RPMh Network-On-Chip Interconnect
>> +
>> +maintainers:
>> +  - Konrad Dybcio <konradybcio@xxxxxxxxxx>
>> +
>> +description:
>> +  RPM interconnect providers support for managing system bandwidth requirements
>> +  through manual requests based on either predefined values or as indicated by
>> +  the bus monitor hardware. Each provider node represents a NoC bus master,
>> +  driven by a dedicated clock source.
>> +
>> +properties:
>> +  '#interconnect-cells':
>> +    oneOf:
>> +      - const: 2
>> +      - const: 1
>> +        deprecated: true
> 
> I think this is kind of questionable for a single property. Do you 
> plan to add more properties here?
My best answer is "we'll see". Not in the forseeable future, but
this hardware has a never-ending queue of surprises..

I like this file for the broader description, but ultimately up to you.

(FWIW Georgi has queued this up for icc-dev (not icc-next) and I'd like
to flush my icc patch queue, but that's just my lazy €0.05)

> Also, if you add a new user of this 
> schema, then it's going to allow the deprecated case when it could just 
> start with 2 only.
I see your point.

Speaking of this keyword, shouldn't the dt checker start spitting out
warnings that would urge dts maintainers to update their trees?

Konrad