Re: [PATCH 1/6] dt-bindings: ptp: Document the TSCSS on Qualcomm Lemans and Monaco SoCs

[Krzysztof Kozlowski <krzk@kernel.org>]

On 01/09/2026 08:31, Imran Shaik wrote:
>>
>>> +  clocks:
>>> +    minItems: 2
>>> +    items:
>>> +      - description: TSC AHB configuration clock.
>>> +      - description: TSC global counter clock.
>>> +      - description: TSC ETU clock.
>>> +
>>> +  clock-names:
>>> +    minItems: 2
>>
>> Why is this flexible?
>>
> 
> Actually, the TSC block can standalone work without the ETU support as
> well. This ETU clock is require only when we add the ETU slice sub
> nodes. Hence, keeping the minItems to 2, excluding the ETU clock.

Hardware either has them or not. Whether they are necessary to
prepared/enabled is independent thing and job for the driver.


> 
>>> +    items:
>>> +      - const: ahb
>>> +      - const: cntr
>>> +      - const: etu
>>> +
>>> +  interrupts:
>>> +    description: Summary interrupt raised based on external event for any of the ETU slices.
>>
>> Please follow Linux coding style.
>>
> 
> Sure, will update.
> 
>>> +    maxItems: 1
>>> +
>>> +  interrupt-names:
>>> +    items:
>>> +      - const: etu_summary
>>> +
>>> +  assigned-clocks: true
>>> +  assigned-clock-rates: true
>>
>> Drop. From where did you take it?
>>
> 
> Actually, we need these properties to be present in the DTS to take care
> of the clock rate requirements.
> 
> Please suggest on how to handle such requirements.

Why does this binding has to be different than ALL other bindings in the
kernel? I am not talking about DTS now.

> 
>>> +
>>> +  "#address-cells":
>>> +    const: 2
>>> +
>>> +  "#size-cells":
>>> +    const: 2
>>> +
>>> +  ranges: true
>>> +
>>> +patternProperties:
>>> +  "^etu-slice@[0-9a-f]+$":
>>> +    type: object
>>> +    description: ETU slice configuration
>>> +    properties:
>>> +      reg:
>>> +        maxItems: 1
>>> +
>>> +      pinctrl-0: true
>>> +
>>> +      pinctrl-names:
>>> +        items:
>>> +          - const: default
>>
>> Heh? Which code do you copy?
>>
> 
> Each ETU slice has its own external event pin config, so kept pinctrl-0
> and pinctrl-names on the slice subnode. Please suggest if you prefer
> otherwise.

No, from where did you get this code? Why are you sending bindings which
are different then all other bindings?


> 
>>> +
>>> +      qcom,etu-event-sel:
>>> +        description: Event selection value for this slice.
>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>> +
>>> +      qcom,etu-slice:
>>> +        description: ETU slice identifier.
>>
>> You do not get identifiers. Please read writing bindings.
>>
> 
> In general, any ETU slice can function with any ETU event sel, and this
> might not be 1-1 always. Also, these ETU slices can be configured by the
> vendors based on the requirements of the GPIOs on the board. Hence, this
> etu-slice identifier will provide the flexibility to configure
> accordingly.

'reg' defines which ETU slice is this, no?


Best regards,
Krzysztof