[V2,4/6] dt-bindings: timestamp: Add Tegra234 support

  Added timestamp provider support for the Tegra234 in devicetree
bindings.

Signed-off-by: Dipen Patel <dipenp@nvidia.com>
---
v2:
- Removed nvidia,slices property
- Added nvidia,gpio-controller based on review comments from Thierry,
  this will help simplify the  hte provider driver.

 .../timestamp/nvidia,tegra194-hte.yaml        | 30 ++++++++++++-------
 1 file changed, 19 insertions(+), 11 deletions(-)
  

On 14/02/2023 12:55, Dipen Patel wrote:
> Added timestamp provider support for the Tegra234 in devicetree
> bindings.

1. Your commit does much more. You need to explain it why you drop some
property.

2. Bindings go before its usage (in the patchset).

3. Please use scripts/get_maintainers.pl to get a list of necessary
people and lists to CC.  It might happen, that command when run on an
older kernel, gives you outdated entries.  Therefore please be sure you
base your patches on recent Linux kernel.


> 
> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
> ---
> v2:
> - Removed nvidia,slices property
> - Added nvidia,gpio-controller based on review comments from Thierry,
>   this will help simplify the  hte provider driver.
> 
>  .../timestamp/nvidia,tegra194-hte.yaml        | 30 ++++++++++++-------
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
> index c31e207d1652..d0f4ed75baee 100644
> --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
> +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
> @@ -4,7 +4,7 @@
>  $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml#
>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>  
> -title: Tegra194 on chip generic hardware timestamping engine (HTE)
> +title: Tegra on chip generic hardware timestamping engine (HTE) provider
>  
>  maintainers:
>    - Dipen Patel <dipenp@nvidia.com>
> @@ -23,6 +23,8 @@ properties:
>      enum:
>        - nvidia,tegra194-gte-aon
>        - nvidia,tegra194-gte-lic
> +      - nvidia,tegra234-gte-aon
> +      - nvidia,tegra234-gte-lic
>  
>    reg:
>      maxItems: 1
> @@ -38,14 +40,11 @@ properties:
>      minimum: 1
>      maximum: 256
>  
> -  nvidia,slices:
> -    $ref: /schemas/types.yaml#/definitions/uint32
> +  nvidia,gpio-controller:
> +    $ref: /schemas/types.yaml#/definitions/phandle
>      description:
> -      HTE lines are arranged in 32 bit slice where each bit represents different
> -      line/signal that it can enable/configure for the timestamp. It is u32
> -      property and depends on the HTE instance in the chip. The value 3 is for
> -      GPIO GTE and 11 for IRQ GTE.
> -    enum: [3, 11]
> +      The phandle to AON gpio controller instance. This is required to handle
> +      namespace conversion between GPIO and GTE.
>  
>    '#timestamp-cells':
>      description:
> @@ -55,11 +54,21 @@ properties:
>        mentioned in the nvidia GPIO device tree binding document.
>      const: 1
>  
> +if:

Keep it under allOf (so you no need to re-indent it on next if statement
in the future) and put entire allOf after "required:".

> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - nvidia,tegra194-gte-aon

This is an ABI break. Does your driver handle it?

> +          - nvidia,tegra234-gte-aon
> +then:
> +  required:
> +    - nvidia,gpio-controller
> +
>  required:
>    - compatible
>    - reg
>    - interrupts
> -  - nvidia,slices
>    - "#timestamp-cells"


Best regards,
Krzysztof
  

On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
> On 14/02/2023 12:55, Dipen Patel wrote:
>> Added timestamp provider support for the Tegra234 in devicetree
>> bindings.
> 
> 1. Your commit does much more. You need to explain it why you drop some
> property.
ACK, will address it next patch
> 
> 2. Bindings go before its usage (in the patchset).
Ack...
> 
> 3. Please use scripts/get_maintainers.pl to get a list of necessary
> people and lists to CC.  It might happen, that command when run on an
> older kernel, gives you outdated entries.  Therefore please be sure you
> base your patches on recent Linux kernel.
It is based on recent linux at the time patch series was sent...
> 
> 
>>
>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>> ---
>> v2:
>> - Removed nvidia,slices property
>> - Added nvidia,gpio-controller based on review comments from Thierry,
>>   this will help simplify the  hte provider driver.
>>
>>  .../timestamp/nvidia,tegra194-hte.yaml        | 30 ++++++++++++-------
>>  1 file changed, 19 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> index c31e207d1652..d0f4ed75baee 100644
>> --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> @@ -4,7 +4,7 @@
>>  $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml#
>>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>>  
>> -title: Tegra194 on chip generic hardware timestamping engine (HTE)
>> +title: Tegra on chip generic hardware timestamping engine (HTE) provider
>>  
>>  maintainers:
>>    - Dipen Patel <dipenp@nvidia.com>
>> @@ -23,6 +23,8 @@ properties:
>>      enum:
>>        - nvidia,tegra194-gte-aon
>>        - nvidia,tegra194-gte-lic
>> +      - nvidia,tegra234-gte-aon
>> +      - nvidia,tegra234-gte-lic
>>  
>>    reg:
>>      maxItems: 1
>> @@ -38,14 +40,11 @@ properties:
>>      minimum: 1
>>      maximum: 256
>>  
>> -  nvidia,slices:
>> -    $ref: /schemas/types.yaml#/definitions/uint32
>> +  nvidia,gpio-controller:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>      description:
>> -      HTE lines are arranged in 32 bit slice where each bit represents different
>> -      line/signal that it can enable/configure for the timestamp. It is u32
>> -      property and depends on the HTE instance in the chip. The value 3 is for
>> -      GPIO GTE and 11 for IRQ GTE.
>> -    enum: [3, 11]
>> +      The phandle to AON gpio controller instance. This is required to handle
>> +      namespace conversion between GPIO and GTE.
>>  
>>    '#timestamp-cells':
>>      description:
>> @@ -55,11 +54,21 @@ properties:
>>        mentioned in the nvidia GPIO device tree binding document.
>>      const: 1
>>  
>> +if:
> 
> Keep it under allOf (so you no need to re-indent it on next if statement
> in the future) and put entire allOf after "required:".
> 
Ack...
>> +  properties:
>> +    compatible:
>> +      contains:
>> +        enum:
>> +          - nvidia,tegra194-gte-aon
> 
> This is an ABI break. Does your driver handle it?
yes, handling patch is part of this patch series.
> 
>> +          - nvidia,tegra234-gte-aon
>> +then:
>> +  required:
>> +    - nvidia,gpio-controller
>> +
>>  required:
>>    - compatible
>>    - reg
>>    - interrupts
>> -  - nvidia,slices
>>    - "#timestamp-cells"
> 
> 
> Best regards,
> Krzysztof
>
  

On 08/03/2023 19:45, Dipen Patel wrote:
> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>> On 14/02/2023 12:55, Dipen Patel wrote:
>>> Added timestamp provider support for the Tegra234 in devicetree
>>> bindings.
>>
>> 1. Your commit does much more. You need to explain it why you drop some
>> property.
> ACK, will address it next patch
>>
>> 2. Bindings go before its usage (in the patchset).
> Ack...
>>
>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>> people and lists to CC.  It might happen, that command when run on an
>> older kernel, gives you outdated entries.  Therefore please be sure you
>> base your patches on recent Linux kernel.
> It is based on recent linux at the time patch series was sent...

That's good but then why you do not use scripts/get_maintainers.pl? The
hint about recent kernel was just a hint... Just do not invent addresses
by yourself and use the tool to get them right.

(...)

>>> +  properties:
>>> +    compatible:
>>> +      contains:
>>> +        enum:
>>> +          - nvidia,tegra194-gte-aon
>>
>> This is an ABI break. Does your driver handle it?
> yes, handling patch is part of this patch series.

Can you point me to the code which does it? I see "return -ENODEV;", so
I think you do not handle ABI break. I could miss something but since
you disagree with me, please at least bring some arguments...


Best regards,
Krzysztof
  

On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
> On 08/03/2023 19:45, Dipen Patel wrote:
>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>> bindings.
>>>
>>> 1. Your commit does much more. You need to explain it why you drop some
>>> property.
>> ACK, will address it next patch
>>>
>>> 2. Bindings go before its usage (in the patchset).
>> Ack...
>>>
>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>> people and lists to CC.  It might happen, that command when run on an
>>> older kernel, gives you outdated entries.  Therefore please be sure you
>>> base your patches on recent Linux kernel.
>> It is based on recent linux at the time patch series was sent...
> 
> That's good but then why you do not use scripts/get_maintainers.pl? The
> hint about recent kernel was just a hint... Just do not invent addresses
> by yourself and use the tool to get them right.
> 
I will take a note for the next patch series to add any missing people. The current
list of people/group is what historically helped review this new timestamp/hte subsystem.

> (...)
> 
>>>> +  properties:
>>>> +    compatible:
>>>> +      contains:
>>>> +        enum:
>>>> +          - nvidia,tegra194-gte-aon
>>>
>>> This is an ABI break. Does your driver handle it?
>> yes, handling patch is part of this patch series.
> 
> Can you point me to the code which does it? I see "return -ENODEV;", so
> I think you do not handle ABI break. I could miss something but since
> you disagree with me, please at least bring some arguments...
Refer to patch https://patchwork.kernel.org/project/timestamp/patch/20230214115553.10416-3-dipenp@nvidia.com/
which has compatible properties added and also code changes to reflect addition/deletion of some
properties.

I am not sure I have understood about ABI break comment. How else one should handle if
there is no related gpio controller property found? I am assuming you are referring to the
below code from the patch 2 (link above) when you said "return -ENODEV".


-		hte_dev->c = gpiochip_find("tegra194-gpio-aon",
-					   tegra_get_gpiochip_from_name);
+		gpio_ctrl = of_parse_phandle(dev->of_node,
+					     "nvidia,gpio-controller", 0);
+		if (!gpio_ctrl) {
+			dev_err(dev, "gpio controller node not found\n");
+			return -ENODEV;
+		}
+
+		hte_dev->c = gpiochip_find(gpio_ctrl,
+					   tegra_get_gpiochip_from_of_node)

> 
> 
> Best regards,
> Krzysztof
>
  

On 08/03/2023 21:09, Dipen Patel wrote:
> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>> On 08/03/2023 19:45, Dipen Patel wrote:
>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>> bindings.
>>>>
>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>> property.
>>> ACK, will address it next patch
>>>>
>>>> 2. Bindings go before its usage (in the patchset).
>>> Ack...
>>>>
>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>> people and lists to CC.  It might happen, that command when run on an
>>>> older kernel, gives you outdated entries.  Therefore please be sure you
>>>> base your patches on recent Linux kernel.
>>> It is based on recent linux at the time patch series was sent...
>>
>> That's good but then why you do not use scripts/get_maintainers.pl? The
>> hint about recent kernel was just a hint... Just do not invent addresses
>> by yourself and use the tool to get them right.
>>
> I will take a note for the next patch series to add any missing people. The current
> list of people/group is what historically helped review this new timestamp/hte subsystem.
> 
>> (...)
>>
>>>>> +  properties:
>>>>> +    compatible:
>>>>> +      contains:
>>>>> +        enum:
>>>>> +          - nvidia,tegra194-gte-aon
>>>>
>>>> This is an ABI break. Does your driver handle it?
>>> yes, handling patch is part of this patch series.
>>
>> Can you point me to the code which does it? I see "return -ENODEV;", so
>> I think you do not handle ABI break. I could miss something but since
>> you disagree with me, please at least bring some arguments...
> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/20230214115553.10416-3-dipenp@nvidia.com/
> which has compatible properties added and also code changes to reflect addition/deletion of some
> properties.

I referred to the code which breaks the ABI.

> 
> I am not sure I have understood about ABI break comment. How else one should handle if
> there is no related gpio controller property found?

In a way it does not break existing users? There are many ways to handle
it, but I don't know your code to point you.

> I am assuming you are referring to the
> below code from the patch 2 (link above) when you said "return -ENODEV".


Your bindings patch points to ABI break without any
explanation/justification. Then your code #2 patch actually breaks it,
also without any justification.

Best regards,
Krzysztof
  

On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
> On 08/03/2023 21:09, Dipen Patel wrote:
>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>> bindings.
>>>>>
>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>> property.
>>>> ACK, will address it next patch
>>>>>
>>>>> 2. Bindings go before its usage (in the patchset).
>>>> Ack...
>>>>>
>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>> people and lists to CC.  It might happen, that command when run on an
>>>>> older kernel, gives you outdated entries.  Therefore please be sure you
>>>>> base your patches on recent Linux kernel.
>>>> It is based on recent linux at the time patch series was sent...
>>>
>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>> hint about recent kernel was just a hint... Just do not invent addresses
>>> by yourself and use the tool to get them right.
>>>
>> I will take a note for the next patch series to add any missing people. The current
>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>
>>> (...)
>>>
>>>>>> +  properties:
>>>>>> +    compatible:
>>>>>> +      contains:
>>>>>> +        enum:
>>>>>> +          - nvidia,tegra194-gte-aon
>>>>>
>>>>> This is an ABI break. Does your driver handle it?
>>>> yes, handling patch is part of this patch series.
>>>
>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>> I think you do not handle ABI break. I could miss something but since
>>> you disagree with me, please at least bring some arguments...
>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/20230214115553.10416-3-dipenp@nvidia.com/
>> which has compatible properties added and also code changes to reflect addition/deletion of some
>> properties.
> 
> I referred to the code which breaks the ABI.
> 
>>
>> I am not sure I have understood about ABI break comment. How else one should handle if
>> there is no related gpio controller property found?
> 
> In a way it does not break existing users? There are many ways to handle
> it, but I don't know your code to point you.

It is new subsystem and has only one driver which uses it so far. This was a decision taken
after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
and necessary changes have been made to existing user. From now on, it has to follow this change.

> 
>> I am assuming you are referring to the
>> below code from the patch 2 (link above) when you said "return -ENODEV".
> 
> 
> Your bindings patch points to ABI break without any
> explanation/justification. Then your code #2 patch actually breaks it,
> also without any justification.
I am going to add explanation/justification in the commit message in the next patch series. But to give
you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-3-dipenp@nvidia.com/

> 
> Best regards,
> Krzysztof
>
  

On 09/03/2023 19:49, Dipen Patel wrote:
> On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
>> On 08/03/2023 21:09, Dipen Patel wrote:
>>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>>> bindings.
>>>>>>
>>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>>> property.
>>>>> ACK, will address it next patch
>>>>>>
>>>>>> 2. Bindings go before its usage (in the patchset).
>>>>> Ack...
>>>>>>
>>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>>> people and lists to CC.  It might happen, that command when run on an
>>>>>> older kernel, gives you outdated entries.  Therefore please be sure you
>>>>>> base your patches on recent Linux kernel.
>>>>> It is based on recent linux at the time patch series was sent...
>>>>
>>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>>> hint about recent kernel was just a hint... Just do not invent addresses
>>>> by yourself and use the tool to get them right.
>>>>
>>> I will take a note for the next patch series to add any missing people. The current
>>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>>
>>>> (...)
>>>>
>>>>>>> +  properties:
>>>>>>> +    compatible:
>>>>>>> +      contains:
>>>>>>> +        enum:
>>>>>>> +          - nvidia,tegra194-gte-aon
>>>>>>
>>>>>> This is an ABI break. Does your driver handle it?
>>>>> yes, handling patch is part of this patch series.
>>>>
>>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>>> I think you do not handle ABI break. I could miss something but since
>>>> you disagree with me, please at least bring some arguments...
>>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/20230214115553.10416-3-dipenp@nvidia.com/
>>> which has compatible properties added and also code changes to reflect addition/deletion of some
>>> properties.
>>
>> I referred to the code which breaks the ABI.
>>
>>>
>>> I am not sure I have understood about ABI break comment. How else one should handle if
>>> there is no related gpio controller property found?
>>
>> In a way it does not break existing users? There are many ways to handle
>> it, but I don't know your code to point you.
> 
> It is new subsystem and has only one driver which uses it so far. 

We do not talk about subsystem, but Tegra SoC, which is not new. Unless
you meant this is new SoC/DTS?

> This was a decision taken
> after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
> and necessary changes have been made to existing user. From now on, it has to follow this change.

What is "it" which has to follow? There are rules for stable ABI and
commit msg does not explain why they should not be followed.

> 
>>
>>> I am assuming you are referring to the
>>> below code from the patch 2 (link above) when you said "return -ENODEV".
>>
>>
>> Your bindings patch points to ABI break without any
>> explanation/justification. Then your code #2 patch actually breaks it,
>> also without any justification.
> I am going to add explanation/justification in the commit message in the next patch series. But to give
> you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-3-dipenp@nvidia.com/

Either too many messages (and I missed something) or I could not find
why ABI break is accepted and justified.


Best regards,
Krzysztof
  

On 3/10/23 12:45 AM, Krzysztof Kozlowski wrote:
> On 09/03/2023 19:49, Dipen Patel wrote:
>> On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
>>> On 08/03/2023 21:09, Dipen Patel wrote:
>>>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>>>> bindings.
>>>>>>>
>>>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>>>> property.
>>>>>> ACK, will address it next patch
>>>>>>>
>>>>>>> 2. Bindings go before its usage (in the patchset).
>>>>>> Ack...
>>>>>>>
>>>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>>>> people and lists to CC.  It might happen, that command when run on an
>>>>>>> older kernel, gives you outdated entries.  Therefore please be sure you
>>>>>>> base your patches on recent Linux kernel.
>>>>>> It is based on recent linux at the time patch series was sent...
>>>>>
>>>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>>>> hint about recent kernel was just a hint... Just do not invent addresses
>>>>> by yourself and use the tool to get them right.
>>>>>
>>>> I will take a note for the next patch series to add any missing people. The current
>>>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>>>
>>>>> (...)
>>>>>
>>>>>>>> +  properties:
>>>>>>>> +    compatible:
>>>>>>>> +      contains:
>>>>>>>> +        enum:
>>>>>>>> +          - nvidia,tegra194-gte-aon
>>>>>>>
>>>>>>> This is an ABI break. Does your driver handle it?
>>>>>> yes, handling patch is part of this patch series.
>>>>>
>>>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>>>> I think you do not handle ABI break. I could miss something but since
>>>>> you disagree with me, please at least bring some arguments...
>>>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/20230214115553.10416-3-dipenp@nvidia.com/
>>>> which has compatible properties added and also code changes to reflect addition/deletion of some
>>>> properties.
>>>
>>> I referred to the code which breaks the ABI.
>>>
>>>>
>>>> I am not sure I have understood about ABI break comment. How else one should handle if
>>>> there is no related gpio controller property found?
>>>
>>> In a way it does not break existing users? There are many ways to handle
>>> it, but I don't know your code to point you.
>>
>> It is new subsystem and has only one driver which uses it so far. 
> 
> We do not talk about subsystem, but Tegra SoC, which is not new. Unless
> you meant this is new SoC/DTS?
> 
>> This was a decision taken
>> after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
>> and necessary changes have been made to existing user. From now on, it has to follow this change.
> 
> What is "it" which has to follow? There are rules for stable ABI and
> commit msg does not explain why they should not be followed.

"It" here means hte-tegra194.c HTE provider which is the only one and not being used by any entity
yet.

> 
>>
>>>
>>>> I am assuming you are referring to the
>>>> below code from the patch 2 (link above) when you said "return -ENODEV".
>>>
>>>
>>> Your bindings patch points to ABI break without any
>>> explanation/justification. Then your code #2 patch actually breaks it,
>>> also without any justification.
>> I am going to add explanation/justification in the commit message in the next patch series. But to give
>> you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-3-dipenp@nvidia.com/
> 
> Either too many messages (and I missed something) or I could not find
> why ABI break is accepted and justified.

https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-5-dipenp@nvidia.com/#3000908 and
affected code/comment at https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-5-dipenp@nvidia.com/#3000908.

Will it help if I send new patch series with detailed commit message?
> 
> 
> Best regards,
> Krzysztof
>
  

On 10/03/2023 18:19, Dipen Patel wrote:
> On 3/10/23 12:45 AM, Krzysztof Kozlowski wrote:
>> On 09/03/2023 19:49, Dipen Patel wrote:
>>> On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
>>>> On 08/03/2023 21:09, Dipen Patel wrote:
>>>>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>>>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>>>>> bindings.
>>>>>>>>
>>>>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>>>>> property.
>>>>>>> ACK, will address it next patch
>>>>>>>>
>>>>>>>> 2. Bindings go before its usage (in the patchset).
>>>>>>> Ack...
>>>>>>>>
>>>>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>>>>> people and lists to CC.  It might happen, that command when run on an
>>>>>>>> older kernel, gives you outdated entries.  Therefore please be sure you
>>>>>>>> base your patches on recent Linux kernel.
>>>>>>> It is based on recent linux at the time patch series was sent...
>>>>>>
>>>>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>>>>> hint about recent kernel was just a hint... Just do not invent addresses
>>>>>> by yourself and use the tool to get them right.
>>>>>>
>>>>> I will take a note for the next patch series to add any missing people. The current
>>>>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>>>>
>>>>>> (...)
>>>>>>
>>>>>>>>> +  properties:
>>>>>>>>> +    compatible:
>>>>>>>>> +      contains:
>>>>>>>>> +        enum:
>>>>>>>>> +          - nvidia,tegra194-gte-aon
>>>>>>>>
>>>>>>>> This is an ABI break. Does your driver handle it?
>>>>>>> yes, handling patch is part of this patch series.
>>>>>>
>>>>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>>>>> I think you do not handle ABI break. I could miss something but since
>>>>>> you disagree with me, please at least bring some arguments...
>>>>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/20230214115553.10416-3-dipenp@nvidia.com/
>>>>> which has compatible properties added and also code changes to reflect addition/deletion of some
>>>>> properties.
>>>>
>>>> I referred to the code which breaks the ABI.
>>>>
>>>>>
>>>>> I am not sure I have understood about ABI break comment. How else one should handle if
>>>>> there is no related gpio controller property found?
>>>>
>>>> In a way it does not break existing users? There are many ways to handle
>>>> it, but I don't know your code to point you.
>>>
>>> It is new subsystem and has only one driver which uses it so far. 
>>
>> We do not talk about subsystem, but Tegra SoC, which is not new. Unless
>> you meant this is new SoC/DTS?
>>
>>> This was a decision taken
>>> after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
>>> and necessary changes have been made to existing user. From now on, it has to follow this change.
>>
>> What is "it" which has to follow? There are rules for stable ABI and
>> commit msg does not explain why they should not be followed.
> 
> "It" here means hte-tegra194.c HTE provider which is the only one and not being used by any entity
> yet.
> 
>>
>>>
>>>>
>>>>> I am assuming you are referring to the
>>>>> below code from the patch 2 (link above) when you said "return -ENODEV".
>>>>
>>>>
>>>> Your bindings patch points to ABI break without any
>>>> explanation/justification. Then your code #2 patch actually breaks it,
>>>> also without any justification.
>>> I am going to add explanation/justification in the commit message in the next patch series. But to give
>>> you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-3-dipenp@nvidia.com/
>>
>> Either too many messages (and I missed something) or I could not find
>> why ABI break is accepted and justified.
> 
> https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-5-dipenp@nvidia.com/#3000908 and
> affected code/comment at https://patchwork.ozlabs.org/project/linux-gpio/patch/20221103174523.29592-5-dipenp@nvidia.com/#3000908.
> 
> Will it help if I send new patch series with detailed commit message?

Yes. If the binding is not used, it's a perfectly valid reason and
should be mentioned in commit msg.

Best regards,
Krzysztof