[PATCH v2 0/3] Fix for arch timer users

[PATCH v2 0/3] Fix for arch timer users

[Kuldeep Singh]

This patchset is an attempt to fix arch timer users and with at it,
resolve dtbs_check warning.

v1 version can be found at below:
https://lore.kernel.org/linux-devicetree/20220316095433.20225-1-singh.kuldeep87k@gmail.com/

v2:
- Add Krzystof Rb tag in patch1
- Reword patch 2 commit message
- Drop v1 patch3 as driver change is not required
- Add new patch3, a fix in Aspeed DT to resolve dtbs_check warning

Patch 1 is done in preparation for following patches which defines
compatibles order in more clear way.
Patch 2 documents arm,cortex-a7-timer entry in bindings similar to an
existing entry arm,cortex-a15-timer.
Patch 3 fix Aspeed DT which is not compliant with binding as of now.

Kuldeep Singh (3):
  dt-bindings: timer: Rearrange compatible entries of arch timer
  dt-bindings: timer: Document arm,cortex-a7-timer in arch timer
  ARM: dts: aspeed: Remove arch timer clocks property

 .../devicetree/bindings/timer/arm,arch_timer.yaml   | 13 +++++--------
 arch/arm/boot/dts/aspeed-g6.dtsi                    |  1 -
 2 files changed, 5 insertions(+), 9 deletions(-)

-- 
2.25.1

[PATCH v2 0/3] Fix for arch timer users

[Kuldeep Singh]

This patchset is an attempt to fix arch timer users and with at it,
resolve dtbs_check warning.

v1 version can be found at below:
https://lore.kernel.org/linux-devicetree/20220316095433.20225-1-singh.kuldeep87k@gmail.com/

v2:
- Add Krzystof Rb tag in patch1
- Reword patch 2 commit message
- Drop v1 patch3 as driver change is not required
- Add new patch3, a fix in Aspeed DT to resolve dtbs_check warning

Patch 1 is done in preparation for following patches which defines
compatibles order in more clear way.
Patch 2 documents arm,cortex-a7-timer entry in bindings similar to an
existing entry arm,cortex-a15-timer.
Patch 3 fix Aspeed DT which is not compliant with binding as of now.

Kuldeep Singh (3):
  dt-bindings: timer: Rearrange compatible entries of arch timer
  dt-bindings: timer: Document arm,cortex-a7-timer in arch timer
  ARM: dts: aspeed: Remove arch timer clocks property

 .../devicetree/bindings/timer/arm,arch_timer.yaml   | 13 +++++--------
 arch/arm/boot/dts/aspeed-g6.dtsi                    |  1 -
 2 files changed, 5 insertions(+), 9 deletions(-)

-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/3] dt-bindings: timer: Rearrange compatible entries of arch timer

[Kuldeep Singh]

Compatibles entries of arch timer includes few extra items and enum
pairs which are redundant and can be simplified in a more clear, concise
and readable way. Do it.

Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
---
 .../devicetree/bindings/timer/arm,arch_timer.yaml    | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index df8ce87fd54b..ba2910f0a7b2 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -21,17 +21,13 @@ description: |+
 properties:
   compatible:
     oneOf:
+      - enum:
+          - arm,armv7-timer
+          - arm,armv8-timer
       - items:
           - enum:
               - arm,cortex-a15-timer
-          - enum:
-              - arm,armv7-timer
-      - items:
-          - enum:
-              - arm,armv7-timer
-      - items:
-          - enum:
-              - arm,armv8-timer
+          - const: arm,armv7-timer
 
   interrupts:
     minItems: 1
-- 
2.25.1

[PATCH v2 1/3] dt-bindings: timer: Rearrange compatible entries of arch timer

[Kuldeep Singh]

Compatibles entries of arch timer includes few extra items and enum
pairs which are redundant and can be simplified in a more clear, concise
and readable way. Do it.

Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
---
 .../devicetree/bindings/timer/arm,arch_timer.yaml    | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index df8ce87fd54b..ba2910f0a7b2 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -21,17 +21,13 @@ description: |+
 properties:
   compatible:
     oneOf:
+      - enum:
+          - arm,armv7-timer
+          - arm,armv8-timer
       - items:
           - enum:
               - arm,cortex-a15-timer
-          - enum:
-              - arm,armv7-timer
-      - items:
-          - enum:
-              - arm,armv7-timer
-      - items:
-          - enum:
-              - arm,armv8-timer
+          - const: arm,armv7-timer
 
   interrupts:
     minItems: 1
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/3] dt-bindings: timer: Document arm,cortex-a7-timer in arch timer

[Kuldeep Singh]

Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
conjugation with "arm,armv7-timer". Since, initial entry is not
documented, it start raising dtbs_check warnings.

['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']

Document this compatible to address it. The motivation to add this
change is taken from an already existing entry "arm,cortex-a15-timer".
Please note, this will not hurt any arch timer users.

Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
---
 Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index ba2910f0a7b2..ea390e5df71d 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -26,6 +26,7 @@ properties:
           - arm,armv8-timer
       - items:
           - enum:
+              - arm,cortex-a7-timer
               - arm,cortex-a15-timer
           - const: arm,armv7-timer
 
-- 
2.25.1

[PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Kuldeep Singh]

Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
conjugation with "arm,armv7-timer". Since, initial entry is not
documented, it start raising dtbs_check warnings.

['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']

Document this compatible to address it. The motivation to add this
change is taken from an already existing entry "arm,cortex-a15-timer".
Please note, this will not hurt any arch timer users.

Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
---
 Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index ba2910f0a7b2..ea390e5df71d 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -26,6 +26,7 @@ properties:
           - arm,armv8-timer
       - items:
           - enum:
+              - arm,cortex-a7-timer
               - arm,cortex-a15-timer
           - const: arm,armv7-timer
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Robin Murphy]

On 2022-03-17 19:15, Kuldeep Singh wrote:
> Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> conjugation with "arm,armv7-timer". Since, initial entry is not
> documented, it start raising dtbs_check warnings.
> 
> ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> 
> Document this compatible to address it. The motivation to add this
> change is taken from an already existing entry "arm,cortex-a15-timer".
> Please note, this will not hurt any arch timer users.

Eh, if it's never been documented or supported, I say just get rid of 
it. The arch timer interface is by definition part of a CPU, and we can 
tell what the CPU is by reading its ID registers. Indeed that's how the 
driver handles the non-zero number of CPU-specific errata that already 
exist - we don't need compatibles for that.

In some ways it might have been nice to have *SoC-specific* compatibles 
given the difficulty some integrators seem to have had in wiring up a 
stable count *to* the interface, but it's not like they could be 
magically added to already-deployed DTs after a bug is discovered, and 
nor could we have mandated them from day 1 just in case and subsequently 
maintained a binding that is just an ever-growing list of every SoC. Oh 
well.

Robin.

> Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
> ---
>   Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> index ba2910f0a7b2..ea390e5df71d 100644
> --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> @@ -26,6 +26,7 @@ properties:
>             - arm,armv8-timer
>         - items:
>             - enum:
> +              - arm,cortex-a7-timer
>                 - arm,cortex-a15-timer
>             - const: arm,armv7-timer
>   

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Robin Murphy]

On 2022-03-17 19:15, Kuldeep Singh wrote:
> Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> conjugation with "arm,armv7-timer". Since, initial entry is not
> documented, it start raising dtbs_check warnings.
> 
> ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> 
> Document this compatible to address it. The motivation to add this
> change is taken from an already existing entry "arm,cortex-a15-timer".
> Please note, this will not hurt any arch timer users.

Eh, if it's never been documented or supported, I say just get rid of 
it. The arch timer interface is by definition part of a CPU, and we can 
tell what the CPU is by reading its ID registers. Indeed that's how the 
driver handles the non-zero number of CPU-specific errata that already 
exist - we don't need compatibles for that.

In some ways it might have been nice to have *SoC-specific* compatibles 
given the difficulty some integrators seem to have had in wiring up a 
stable count *to* the interface, but it's not like they could be 
magically added to already-deployed DTs after a bug is discovered, and 
nor could we have mandated them from day 1 just in case and subsequently 
maintained a binding that is just an ever-growing list of every SoC. Oh 
well.

Robin.

> Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
> ---
>   Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> index ba2910f0a7b2..ea390e5df71d 100644
> --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> @@ -26,6 +26,7 @@ properties:
>             - arm,armv8-timer
>         - items:
>             - enum:
> +              - arm,cortex-a7-timer
>                 - arm,cortex-a15-timer
>             - const: arm,armv7-timer
>   

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Kuldeep Singh]

On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> On 2022-03-17 19:15, Kuldeep Singh wrote:
> > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > conjugation with "arm,armv7-timer". Since, initial entry is not
> > documented, it start raising dtbs_check warnings.
> > 
> > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > 
> > Document this compatible to address it. The motivation to add this
> > change is taken from an already existing entry "arm,cortex-a15-timer".
> > Please note, this will not hurt any arch timer users.
> 
> Eh, if it's never been documented or supported, I say just get rid of it.
> The arch timer interface is by definition part of a CPU, and we can tell
> what the CPU is by reading its ID registers. Indeed that's how the driver
> handles the non-zero number of CPU-specific errata that already exist - we
> don't need compatibles for that.
> 
> In some ways it might have been nice to have *SoC-specific* compatibles
> given the difficulty some integrators seem to have had in wiring up a stable
> count *to* the interface, but it's not like they could be magically added to
> already-deployed DTs after a bug is discovered, and nor could we have
> mandated them from day 1 just in case and subsequently maintained a binding
> that is just an ever-growing list of every SoC. Oh well.

Robin, A similar discussion was already done on v1 thread. Please see
below for details:
https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/

And final outcome of discussion turns out to add this compatible string.

I see people with different set of perspective in regard to whether keep
compatible string or not. We should have some sort of evidences to
support claims so that next time when similar situation arises, we'll be
aware beforehand how to proceed.

- Kuldeep
> 
> Robin.
> 
> > Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
> > ---
> >   Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > index ba2910f0a7b2..ea390e5df71d 100644
> > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > @@ -26,6 +26,7 @@ properties:
> >             - arm,armv8-timer
> >         - items:
> >             - enum:
> > +              - arm,cortex-a7-timer
> >                 - arm,cortex-a15-timer
> >             - const: arm,armv7-timer

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Kuldeep Singh]

On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> On 2022-03-17 19:15, Kuldeep Singh wrote:
> > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > conjugation with "arm,armv7-timer". Since, initial entry is not
> > documented, it start raising dtbs_check warnings.
> > 
> > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > 
> > Document this compatible to address it. The motivation to add this
> > change is taken from an already existing entry "arm,cortex-a15-timer".
> > Please note, this will not hurt any arch timer users.
> 
> Eh, if it's never been documented or supported, I say just get rid of it.
> The arch timer interface is by definition part of a CPU, and we can tell
> what the CPU is by reading its ID registers. Indeed that's how the driver
> handles the non-zero number of CPU-specific errata that already exist - we
> don't need compatibles for that.
> 
> In some ways it might have been nice to have *SoC-specific* compatibles
> given the difficulty some integrators seem to have had in wiring up a stable
> count *to* the interface, but it's not like they could be magically added to
> already-deployed DTs after a bug is discovered, and nor could we have
> mandated them from day 1 just in case and subsequently maintained a binding
> that is just an ever-growing list of every SoC. Oh well.

Robin, A similar discussion was already done on v1 thread. Please see
below for details:
https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/

And final outcome of discussion turns out to add this compatible string.

I see people with different set of perspective in regard to whether keep
compatible string or not. We should have some sort of evidences to
support claims so that next time when similar situation arises, we'll be
aware beforehand how to proceed.

- Kuldeep
> 
> Robin.
> 
> > Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
> > ---
> >   Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > index ba2910f0a7b2..ea390e5df71d 100644
> > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
> > @@ -26,6 +26,7 @@ properties:
> >             - arm,armv8-timer
> >         - items:
> >             - enum:
> > +              - arm,cortex-a7-timer
> >                 - arm,cortex-a15-timer
> >             - const: arm,armv7-timer

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Rob Herring]

On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > documented, it start raising dtbs_check warnings.
> > > 
> > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > 
> > > Document this compatible to address it. The motivation to add this
> > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > Please note, this will not hurt any arch timer users.
> > 
> > Eh, if it's never been documented or supported, I say just get rid of it.
> > The arch timer interface is by definition part of a CPU, and we can tell
> > what the CPU is by reading its ID registers. Indeed that's how the driver
> > handles the non-zero number of CPU-specific errata that already exist - we
> > don't need compatibles for that.
> > 
> > In some ways it might have been nice to have *SoC-specific* compatibles
> > given the difficulty some integrators seem to have had in wiring up a stable
> > count *to* the interface, but it's not like they could be magically added to
> > already-deployed DTs after a bug is discovered, and nor could we have
> > mandated them from day 1 just in case and subsequently maintained a binding
> > that is just an ever-growing list of every SoC. Oh well.
> 
> Robin, A similar discussion was already done on v1 thread. Please see
> below for details:
> https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> 
> And final outcome of discussion turns out to add this compatible string.

I agree with Robin on dropping. More specific here is not useful. If 
we're going to add some cores, then we should add every core 
implementation.

If one has a big.LITTLE system with A15/A7 what would be the right 
compatible value?

> 
> I see people with different set of perspective in regard to whether keep
> compatible string or not. We should have some sort of evidences to
> support claims so that next time when similar situation arises, we'll be
> aware beforehand how to proceed.

Every situation tends to be different.

Rob

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Rob Herring]

On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > documented, it start raising dtbs_check warnings.
> > > 
> > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > 
> > > Document this compatible to address it. The motivation to add this
> > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > Please note, this will not hurt any arch timer users.
> > 
> > Eh, if it's never been documented or supported, I say just get rid of it.
> > The arch timer interface is by definition part of a CPU, and we can tell
> > what the CPU is by reading its ID registers. Indeed that's how the driver
> > handles the non-zero number of CPU-specific errata that already exist - we
> > don't need compatibles for that.
> > 
> > In some ways it might have been nice to have *SoC-specific* compatibles
> > given the difficulty some integrators seem to have had in wiring up a stable
> > count *to* the interface, but it's not like they could be magically added to
> > already-deployed DTs after a bug is discovered, and nor could we have
> > mandated them from day 1 just in case and subsequently maintained a binding
> > that is just an ever-growing list of every SoC. Oh well.
> 
> Robin, A similar discussion was already done on v1 thread. Please see
> below for details:
> https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> 
> And final outcome of discussion turns out to add this compatible string.

I agree with Robin on dropping. More specific here is not useful. If 
we're going to add some cores, then we should add every core 
implementation.

If one has a big.LITTLE system with A15/A7 what would be the right 
compatible value?

> 
> I see people with different set of perspective in regard to whether keep
> compatible string or not. We should have some sort of evidences to
> support claims so that next time when similar situation arises, we'll be
> aware beforehand how to proceed.

Every situation tends to be different.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Robin Murphy]

On 2022-03-20 18:47, Rob Herring wrote:
> On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
>> On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
>>> On 2022-03-17 19:15, Kuldeep Singh wrote:
>>>> Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
>>>> conjugation with "arm,armv7-timer". Since, initial entry is not
>>>> documented, it start raising dtbs_check warnings.
>>>>
>>>> ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
>>>> 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
>>>> 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
>>>>
>>>> Document this compatible to address it. The motivation to add this
>>>> change is taken from an already existing entry "arm,cortex-a15-timer".
>>>> Please note, this will not hurt any arch timer users.
>>>
>>> Eh, if it's never been documented or supported, I say just get rid of it.
>>> The arch timer interface is by definition part of a CPU, and we can tell
>>> what the CPU is by reading its ID registers. Indeed that's how the driver
>>> handles the non-zero number of CPU-specific errata that already exist - we
>>> don't need compatibles for that.
>>>
>>> In some ways it might have been nice to have *SoC-specific* compatibles
>>> given the difficulty some integrators seem to have had in wiring up a stable
>>> count *to* the interface, but it's not like they could be magically added to
>>> already-deployed DTs after a bug is discovered, and nor could we have
>>> mandated them from day 1 just in case and subsequently maintained a binding
>>> that is just an ever-growing list of every SoC. Oh well.
>>
>> Robin, A similar discussion was already done on v1 thread. Please see
>> below for details:
>> https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
>> https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
>>
>> And final outcome of discussion turns out to add this compatible string.
> 
> I agree with Robin on dropping. More specific here is not useful. If
> we're going to add some cores, then we should add every core
> implementation.

Yeah, what I was trying to convey is that a compatible like 
"arm,cortex-a76-timer" has the problem of being both too specific *and* 
not specific enough to be genuinely useful *for the particular case of 
the arch timer*. It's an architectural interface, where the actual 
functional features are described through the interface itself, so the 
purpose of the DT entry is really just to indicate that the standard 
interface is present and describe how its externally-routed interrupts 
are wired up.

However, it's also true that implementations of standard functionality 
sometimes have bugs that software needs to know about, but in order for 
specific DT compatibles to be useful in that respect they really need to 
identify the *exact* implementation, e.g. to know that 
"arm,cortex-a76-r0p0-timer" has a bug which needs working around, but 
"arm,cortex-a76-r4p0-timer" does not. There might be cases where every 
known version of a CPU is equally affected (e.g. Cortex-A73), but it 
doesn't hold as a general assumption. Furthermore as mentioned, the 
other class of bugs which affect this interface are not in the CPU's 
implementation of the interface at all, but in the external SoC logic 
that provides the counter value, and therefore it can be identification 
of the overall SoC that matters regardless of which CPU IP(s) may be 
present.

If we'd had the benefit of 10 years worth of hindsight 10 years ago, we 
probably wouldn't have defined "arm,cortex-a15-timer" either. However 
the fact that we can't erase the legacy of that decision doesn't make an 
argument for repeating it now.

> If one has a big.LITTLE system with A15/A7 what would be the right
> compatible value?
> 
>>
>> I see people with different set of perspective in regard to whether keep
>> compatible string or not. We should have some sort of evidences to
>> support claims so that next time when similar situation arises, we'll be
>> aware beforehand how to proceed.
> 
> Every situation tends to be different.

Indeed, I certainly don't have a personal perspective of "delete all the 
bindings!" in general - only when they're truly redundant (functionally, 
any driver that can touch the arch timer registers can also read the CPU 
ID registers, but even in the DT there should already be compatibles for 
the CPUs themselves).

Robin.

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Robin Murphy]

On 2022-03-20 18:47, Rob Herring wrote:
> On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
>> On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
>>> On 2022-03-17 19:15, Kuldeep Singh wrote:
>>>> Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
>>>> conjugation with "arm,armv7-timer". Since, initial entry is not
>>>> documented, it start raising dtbs_check warnings.
>>>>
>>>> ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
>>>> 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
>>>> 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
>>>>
>>>> Document this compatible to address it. The motivation to add this
>>>> change is taken from an already existing entry "arm,cortex-a15-timer".
>>>> Please note, this will not hurt any arch timer users.
>>>
>>> Eh, if it's never been documented or supported, I say just get rid of it.
>>> The arch timer interface is by definition part of a CPU, and we can tell
>>> what the CPU is by reading its ID registers. Indeed that's how the driver
>>> handles the non-zero number of CPU-specific errata that already exist - we
>>> don't need compatibles for that.
>>>
>>> In some ways it might have been nice to have *SoC-specific* compatibles
>>> given the difficulty some integrators seem to have had in wiring up a stable
>>> count *to* the interface, but it's not like they could be magically added to
>>> already-deployed DTs after a bug is discovered, and nor could we have
>>> mandated them from day 1 just in case and subsequently maintained a binding
>>> that is just an ever-growing list of every SoC. Oh well.
>>
>> Robin, A similar discussion was already done on v1 thread. Please see
>> below for details:
>> https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
>> https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
>>
>> And final outcome of discussion turns out to add this compatible string.
> 
> I agree with Robin on dropping. More specific here is not useful. If
> we're going to add some cores, then we should add every core
> implementation.

Yeah, what I was trying to convey is that a compatible like 
"arm,cortex-a76-timer" has the problem of being both too specific *and* 
not specific enough to be genuinely useful *for the particular case of 
the arch timer*. It's an architectural interface, where the actual 
functional features are described through the interface itself, so the 
purpose of the DT entry is really just to indicate that the standard 
interface is present and describe how its externally-routed interrupts 
are wired up.

However, it's also true that implementations of standard functionality 
sometimes have bugs that software needs to know about, but in order for 
specific DT compatibles to be useful in that respect they really need to 
identify the *exact* implementation, e.g. to know that 
"arm,cortex-a76-r0p0-timer" has a bug which needs working around, but 
"arm,cortex-a76-r4p0-timer" does not. There might be cases where every 
known version of a CPU is equally affected (e.g. Cortex-A73), but it 
doesn't hold as a general assumption. Furthermore as mentioned, the 
other class of bugs which affect this interface are not in the CPU's 
implementation of the interface at all, but in the external SoC logic 
that provides the counter value, and therefore it can be identification 
of the overall SoC that matters regardless of which CPU IP(s) may be 
present.

If we'd had the benefit of 10 years worth of hindsight 10 years ago, we 
probably wouldn't have defined "arm,cortex-a15-timer" either. However 
the fact that we can't erase the legacy of that decision doesn't make an 
argument for repeating it now.

> If one has a big.LITTLE system with A15/A7 what would be the right
> compatible value?
> 
>>
>> I see people with different set of perspective in regard to whether keep
>> compatible string or not. We should have some sort of evidences to
>> support claims so that next time when similar situation arises, we'll be
>> aware beforehand how to proceed.
> 
> Every situation tends to be different.

Indeed, I certainly don't have a personal perspective of "delete all the 
bindings!" in general - only when they're truly redundant (functionally, 
any driver that can touch the arch timer registers can also read the CPU 
ID registers, but even in the DT there should already be compatibles for 
the CPUs themselves).

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Kuldeep Singh]

On Mon, Mar 21, 2022 at 11:52:27AM +0000, Robin Murphy wrote:
> On 2022-03-20 18:47, Rob Herring wrote:
> > On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> > > On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > > > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > > > documented, it start raising dtbs_check warnings.
> > > > > 
> > > > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > > > 
> > > > > Document this compatible to address it. The motivation to add this
> > > > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > > > Please note, this will not hurt any arch timer users.
> > > > 
> > > > Eh, if it's never been documented or supported, I say just get rid of it.
> > > > The arch timer interface is by definition part of a CPU, and we can tell
> > > > what the CPU is by reading its ID registers. Indeed that's how the driver
> > > > handles the non-zero number of CPU-specific errata that already exist - we
> > > > don't need compatibles for that.
> > > > 
> > > > In some ways it might have been nice to have *SoC-specific* compatibles
> > > > given the difficulty some integrators seem to have had in wiring up a stable
> > > > count *to* the interface, but it's not like they could be magically added to
> > > > already-deployed DTs after a bug is discovered, and nor could we have
> > > > mandated them from day 1 just in case and subsequently maintained a binding
> > > > that is just an ever-growing list of every SoC. Oh well.
> > > 
> > > Robin, A similar discussion was already done on v1 thread. Please see
> > > below for details:
> > > https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> > > https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> > > 
> > > And final outcome of discussion turns out to add this compatible string.
> > 
> > I agree with Robin on dropping. More specific here is not useful. If
> > we're going to add some cores, then we should add every core
> > implementation.

Sure Rob, I will drop A7/15-timer entry from compatibles.
This means only two entries i.e arm,armv7/8-timer will be there under
compatibles now.

I actually added A7-timer because A15-timer was already present in
binding. Since, it was added by you that's why I added this one.
I will update compatibles accordingly as you said above.

> 
> Yeah, what I was trying to convey is that a compatible like
> "arm,cortex-a76-timer" has the problem of being both too specific *and* not
> specific enough to be genuinely useful *for the particular case of the arch
> timer*. It's an architectural interface, where the actual functional
> features are described through the interface itself, so the purpose of the
> DT entry is really just to indicate that the standard interface is present
> and describe how its externally-routed interrupts are wired up.
> 
> However, it's also true that implementations of standard functionality
> sometimes have bugs that software needs to know about, but in order for
> specific DT compatibles to be useful in that respect they really need to
> identify the *exact* implementation, e.g. to know that
> "arm,cortex-a76-r0p0-timer" has a bug which needs working around, but
> "arm,cortex-a76-r4p0-timer" does not. There might be cases where every known
> version of a CPU is equally affected (e.g. Cortex-A73), but it doesn't hold
> as a general assumption. Furthermore as mentioned, the other class of bugs
> which affect this interface are not in the CPU's implementation of the
> interface at all, but in the external SoC logic that provides the counter
> value, and therefore it can be identification of the overall SoC that
> matters regardless of which CPU IP(s) may be present.
> 
> If we'd had the benefit of 10 years worth of hindsight 10 years ago, we
> probably wouldn't have defined "arm,cortex-a15-timer" either. However the
> fact that we can't erase the legacy of that decision doesn't make an
> argument for repeating it now.
> 
> > If one has a big.LITTLE system with A15/A7 what would be the right
> > compatible value?
> > 
> > > 
> > > I see people with different set of perspective in regard to whether keep
> > > compatible string or not. We should have some sort of evidences to
> > > support claims so that next time when similar situation arises, we'll be
> > > aware beforehand how to proceed.
> > 
> > Every situation tends to be different.
> 
> Indeed, I certainly don't have a personal perspective of "delete all the
> bindings!" in general - only when they're truly redundant (functionally, any
> driver that can touch the arch timer registers can also read the CPU ID
> registers, but even in the DT there should already be compatibles for the
> CPUs themselves).

Thanks Robin for providing inputs.
I agree with your opinion of having soc specific compatibles which is
also mentioned under dos and dont's of bindings and other cases will
require investigation though.
https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html

- Kuldeep

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Kuldeep Singh]

On Mon, Mar 21, 2022 at 11:52:27AM +0000, Robin Murphy wrote:
> On 2022-03-20 18:47, Rob Herring wrote:
> > On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> > > On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > > > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > > > documented, it start raising dtbs_check warnings.
> > > > > 
> > > > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > > > 
> > > > > Document this compatible to address it. The motivation to add this
> > > > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > > > Please note, this will not hurt any arch timer users.
> > > > 
> > > > Eh, if it's never been documented or supported, I say just get rid of it.
> > > > The arch timer interface is by definition part of a CPU, and we can tell
> > > > what the CPU is by reading its ID registers. Indeed that's how the driver
> > > > handles the non-zero number of CPU-specific errata that already exist - we
> > > > don't need compatibles for that.
> > > > 
> > > > In some ways it might have been nice to have *SoC-specific* compatibles
> > > > given the difficulty some integrators seem to have had in wiring up a stable
> > > > count *to* the interface, but it's not like they could be magically added to
> > > > already-deployed DTs after a bug is discovered, and nor could we have
> > > > mandated them from day 1 just in case and subsequently maintained a binding
> > > > that is just an ever-growing list of every SoC. Oh well.
> > > 
> > > Robin, A similar discussion was already done on v1 thread. Please see
> > > below for details:
> > > https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> > > https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> > > 
> > > And final outcome of discussion turns out to add this compatible string.
> > 
> > I agree with Robin on dropping. More specific here is not useful. If
> > we're going to add some cores, then we should add every core
> > implementation.

Sure Rob, I will drop A7/15-timer entry from compatibles.
This means only two entries i.e arm,armv7/8-timer will be there under
compatibles now.

I actually added A7-timer because A15-timer was already present in
binding. Since, it was added by you that's why I added this one.
I will update compatibles accordingly as you said above.

> 
> Yeah, what I was trying to convey is that a compatible like
> "arm,cortex-a76-timer" has the problem of being both too specific *and* not
> specific enough to be genuinely useful *for the particular case of the arch
> timer*. It's an architectural interface, where the actual functional
> features are described through the interface itself, so the purpose of the
> DT entry is really just to indicate that the standard interface is present
> and describe how its externally-routed interrupts are wired up.
> 
> However, it's also true that implementations of standard functionality
> sometimes have bugs that software needs to know about, but in order for
> specific DT compatibles to be useful in that respect they really need to
> identify the *exact* implementation, e.g. to know that
> "arm,cortex-a76-r0p0-timer" has a bug which needs working around, but
> "arm,cortex-a76-r4p0-timer" does not. There might be cases where every known
> version of a CPU is equally affected (e.g. Cortex-A73), but it doesn't hold
> as a general assumption. Furthermore as mentioned, the other class of bugs
> which affect this interface are not in the CPU's implementation of the
> interface at all, but in the external SoC logic that provides the counter
> value, and therefore it can be identification of the overall SoC that
> matters regardless of which CPU IP(s) may be present.
> 
> If we'd had the benefit of 10 years worth of hindsight 10 years ago, we
> probably wouldn't have defined "arm,cortex-a15-timer" either. However the
> fact that we can't erase the legacy of that decision doesn't make an
> argument for repeating it now.
> 
> > If one has a big.LITTLE system with A15/A7 what would be the right
> > compatible value?
> > 
> > > 
> > > I see people with different set of perspective in regard to whether keep
> > > compatible string or not. We should have some sort of evidences to
> > > support claims so that next time when similar situation arises, we'll be
> > > aware beforehand how to proceed.
> > 
> > Every situation tends to be different.
> 
> Indeed, I certainly don't have a personal perspective of "delete all the
> bindings!" in general - only when they're truly redundant (functionally, any
> driver that can touch the arch timer registers can also read the CPU ID
> registers, but even in the DT there should already be compatibles for the
> CPUs themselves).

Thanks Robin for providing inputs.
I agree with your opinion of having soc specific compatibles which is
also mentioned under dos and dont's of bindings and other cases will
require investigation though.
https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html

- Kuldeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Rob Herring]

On Thu, Mar 24, 2022 at 12:05:44AM +0530, Kuldeep Singh wrote:
> On Mon, Mar 21, 2022 at 11:52:27AM +0000, Robin Murphy wrote:
> > On 2022-03-20 18:47, Rob Herring wrote:
> > > On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> > > > On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > > > > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > > > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > > > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > > > > documented, it start raising dtbs_check warnings.
> > > > > > 
> > > > > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > > > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > > > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > > > > 
> > > > > > Document this compatible to address it. The motivation to add this
> > > > > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > > > > Please note, this will not hurt any arch timer users.
> > > > > 
> > > > > Eh, if it's never been documented or supported, I say just get rid of it.
> > > > > The arch timer interface is by definition part of a CPU, and we can tell
> > > > > what the CPU is by reading its ID registers. Indeed that's how the driver
> > > > > handles the non-zero number of CPU-specific errata that already exist - we
> > > > > don't need compatibles for that.
> > > > > 
> > > > > In some ways it might have been nice to have *SoC-specific* compatibles
> > > > > given the difficulty some integrators seem to have had in wiring up a stable
> > > > > count *to* the interface, but it's not like they could be magically added to
> > > > > already-deployed DTs after a bug is discovered, and nor could we have
> > > > > mandated them from day 1 just in case and subsequently maintained a binding
> > > > > that is just an ever-growing list of every SoC. Oh well.
> > > > 
> > > > Robin, A similar discussion was already done on v1 thread. Please see
> > > > below for details:
> > > > https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> > > > https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> > > > 
> > > > And final outcome of discussion turns out to add this compatible string.
> > > 
> > > I agree with Robin on dropping. More specific here is not useful. If
> > > we're going to add some cores, then we should add every core
> > > implementation.
> 
> Sure Rob, I will drop A7/15-timer entry from compatibles.
> This means only two entries i.e arm,armv7/8-timer will be there under
> compatibles now.
> 
> I actually added A7-timer because A15-timer was already present in
> binding. Since, it was added by you that's why I added this one.
> I will update compatibles accordingly as you said above.

The A15 compatible is likely there because upstream dts files used it 
and it's a judgement call of supporting in the schema vs. making dts 
changes. Just like the PL022. Maybe there are A7 cases, but fewer to 
fix. I don't remember.

So no real object to removing it, but I can think of better things to 
work on. Here's a list of most occurring compatibles with no schema[1]. 
Or find a platform and work towards getting 0 warnings.


> > Yeah, what I was trying to convey is that a compatible like
> > "arm,cortex-a76-timer" has the problem of being both too specific *and* not
> > specific enough to be genuinely useful *for the particular case of the arch
> > timer*. It's an architectural interface, where the actual functional
> > features are described through the interface itself, so the purpose of the
> > DT entry is really just to indicate that the standard interface is present
> > and describe how its externally-routed interrupts are wired up.
> > 
> > However, it's also true that implementations of standard functionality
> > sometimes have bugs that software needs to know about, but in order for
> > specific DT compatibles to be useful in that respect they really need to
> > identify the *exact* implementation, e.g. to know that
> > "arm,cortex-a76-r0p0-timer" has a bug which needs working around, but
> > "arm,cortex-a76-r4p0-timer" does not. There might be cases where every known
> > version of a CPU is equally affected (e.g. Cortex-A73), but it doesn't hold
> > as a general assumption. Furthermore as mentioned, the other class of bugs
> > which affect this interface are not in the CPU's implementation of the
> > interface at all, but in the external SoC logic that provides the counter
> > value, and therefore it can be identification of the overall SoC that
> > matters regardless of which CPU IP(s) may be present.
> > 
> > If we'd had the benefit of 10 years worth of hindsight 10 years ago, we
> > probably wouldn't have defined "arm,cortex-a15-timer" either. However the
> > fact that we can't erase the legacy of that decision doesn't make an
> > argument for repeating it now.
> > 
> > > If one has a big.LITTLE system with A15/A7 what would be the right
> > > compatible value?
> > > 
> > > > 
> > > > I see people with different set of perspective in regard to whether keep
> > > > compatible string or not. We should have some sort of evidences to
> > > > support claims so that next time when similar situation arises, we'll be
> > > > aware beforehand how to proceed.
> > > 
> > > Every situation tends to be different.
> > 
> > Indeed, I certainly don't have a personal perspective of "delete all the
> > bindings!" in general - only when they're truly redundant (functionally, any
> > driver that can touch the arch timer registers can also read the CPU ID
> > registers, but even in the DT there should already be compatibles for the
> > CPUs themselves).
> 
> Thanks Robin for providing inputs.
> I agree with your opinion of having soc specific compatibles which is
> also mentioned under dos and dont's of bindings and other cases will
> require investigation though.
> https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html

There's always exceptions to guidelines. This is one of them.

Rob

[1] https://gitlab.com/robherring/linux-dt/-/jobs/2250856818#L7769

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Rob Herring]

On Thu, Mar 24, 2022 at 12:05:44AM +0530, Kuldeep Singh wrote:
> On Mon, Mar 21, 2022 at 11:52:27AM +0000, Robin Murphy wrote:
> > On 2022-03-20 18:47, Rob Herring wrote:
> > > On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> > > > On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > > > > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > > > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > > > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > > > > documented, it start raising dtbs_check warnings.
> > > > > > 
> > > > > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > > > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > > > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > > > > 
> > > > > > Document this compatible to address it. The motivation to add this
> > > > > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > > > > Please note, this will not hurt any arch timer users.
> > > > > 
> > > > > Eh, if it's never been documented or supported, I say just get rid of it.
> > > > > The arch timer interface is by definition part of a CPU, and we can tell
> > > > > what the CPU is by reading its ID registers. Indeed that's how the driver
> > > > > handles the non-zero number of CPU-specific errata that already exist - we
> > > > > don't need compatibles for that.
> > > > > 
> > > > > In some ways it might have been nice to have *SoC-specific* compatibles
> > > > > given the difficulty some integrators seem to have had in wiring up a stable
> > > > > count *to* the interface, but it's not like they could be magically added to
> > > > > already-deployed DTs after a bug is discovered, and nor could we have
> > > > > mandated them from day 1 just in case and subsequently maintained a binding
> > > > > that is just an ever-growing list of every SoC. Oh well.
> > > > 
> > > > Robin, A similar discussion was already done on v1 thread. Please see
> > > > below for details:
> > > > https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> > > > https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> > > > 
> > > > And final outcome of discussion turns out to add this compatible string.
> > > 
> > > I agree with Robin on dropping. More specific here is not useful. If
> > > we're going to add some cores, then we should add every core
> > > implementation.
> 
> Sure Rob, I will drop A7/15-timer entry from compatibles.
> This means only two entries i.e arm,armv7/8-timer will be there under
> compatibles now.
> 
> I actually added A7-timer because A15-timer was already present in
> binding. Since, it was added by you that's why I added this one.
> I will update compatibles accordingly as you said above.

The A15 compatible is likely there because upstream dts files used it 
and it's a judgement call of supporting in the schema vs. making dts 
changes. Just like the PL022. Maybe there are A7 cases, but fewer to 
fix. I don't remember.

So no real object to removing it, but I can think of better things to 
work on. Here's a list of most occurring compatibles with no schema[1]. 
Or find a platform and work towards getting 0 warnings.


> > Yeah, what I was trying to convey is that a compatible like
> > "arm,cortex-a76-timer" has the problem of being both too specific *and* not
> > specific enough to be genuinely useful *for the particular case of the arch
> > timer*. It's an architectural interface, where the actual functional
> > features are described through the interface itself, so the purpose of the
> > DT entry is really just to indicate that the standard interface is present
> > and describe how its externally-routed interrupts are wired up.
> > 
> > However, it's also true that implementations of standard functionality
> > sometimes have bugs that software needs to know about, but in order for
> > specific DT compatibles to be useful in that respect they really need to
> > identify the *exact* implementation, e.g. to know that
> > "arm,cortex-a76-r0p0-timer" has a bug which needs working around, but
> > "arm,cortex-a76-r4p0-timer" does not. There might be cases where every known
> > version of a CPU is equally affected (e.g. Cortex-A73), but it doesn't hold
> > as a general assumption. Furthermore as mentioned, the other class of bugs
> > which affect this interface are not in the CPU's implementation of the
> > interface at all, but in the external SoC logic that provides the counter
> > value, and therefore it can be identification of the overall SoC that
> > matters regardless of which CPU IP(s) may be present.
> > 
> > If we'd had the benefit of 10 years worth of hindsight 10 years ago, we
> > probably wouldn't have defined "arm,cortex-a15-timer" either. However the
> > fact that we can't erase the legacy of that decision doesn't make an
> > argument for repeating it now.
> > 
> > > If one has a big.LITTLE system with A15/A7 what would be the right
> > > compatible value?
> > > 
> > > > 
> > > > I see people with different set of perspective in regard to whether keep
> > > > compatible string or not. We should have some sort of evidences to
> > > > support claims so that next time when similar situation arises, we'll be
> > > > aware beforehand how to proceed.
> > > 
> > > Every situation tends to be different.
> > 
> > Indeed, I certainly don't have a personal perspective of "delete all the
> > bindings!" in general - only when they're truly redundant (functionally, any
> > driver that can touch the arch timer registers can also read the CPU ID
> > registers, but even in the DT there should already be compatibles for the
> > CPUs themselves).
> 
> Thanks Robin for providing inputs.
> I agree with your opinion of having soc specific compatibles which is
> also mentioned under dos and dont's of bindings and other cases will
> require investigation though.
> https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html

There's always exceptions to guidelines. This is one of them.

Rob

[1] https://gitlab.com/robherring/linux-dt/-/jobs/2250856818#L7769

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Geert Uytterhoeven]

On Sun, Mar 20, 2022 at 7:56 PM Rob Herring <robh@kernel.org> wrote:
> On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> > On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > > documented, it start raising dtbs_check warnings.

I hadn't seen this thread, but I had already removed the unneeded
compatible value locally, and was just waiting for the merge window and
holidays to end for sending the patch...

> > > >
> > > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > >
> > > > Document this compatible to address it. The motivation to add this
> > > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > > Please note, this will not hurt any arch timer users.
> > >
> > > Eh, if it's never been documented or supported, I say just get rid of it.
> > > The arch timer interface is by definition part of a CPU, and we can tell
> > > what the CPU is by reading its ID registers. Indeed that's how the driver
> > > handles the non-zero number of CPU-specific errata that already exist - we
> > > don't need compatibles for that.
> > >
> > > In some ways it might have been nice to have *SoC-specific* compatibles
> > > given the difficulty some integrators seem to have had in wiring up a stable
> > > count *to* the interface, but it's not like they could be magically added to
> > > already-deployed DTs after a bug is discovered, and nor could we have
> > > mandated them from day 1 just in case and subsequently maintained a binding
> > > that is just an ever-growing list of every SoC. Oh well.
> >
> > Robin, A similar discussion was already done on v1 thread. Please see
> > below for details:
> > https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> > https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> >
> > And final outcome of discussion turns out to add this compatible string.
>
> I agree with Robin on dropping. More specific here is not useful. If
> we're going to add some cores, then we should add every core
> implementation.

... So consider it gone.

https://lore.kernel.org/r/a8e0cf00a983b4c539cdb1cfad5cc6b10b423c5b.1649680220.git.geert+renesas@glider.be/

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 2/3] dt-bindings: timer: Document arm, cortex-a7-timer in arch timer

[Geert Uytterhoeven]

On Sun, Mar 20, 2022 at 7:56 PM Rob Herring <robh@kernel.org> wrote:
> On Fri, Mar 18, 2022 at 02:55:08AM +0530, Kuldeep Singh wrote:
> > On Thu, Mar 17, 2022 at 08:25:12PM +0000, Robin Murphy wrote:
> > > On 2022-03-17 19:15, Kuldeep Singh wrote:
> > > > Renesas RZ/N1D platform uses compatible "arm,cortex-a7-timer" in
> > > > conjugation with "arm,armv7-timer". Since, initial entry is not
> > > > documented, it start raising dtbs_check warnings.

I hadn't seen this thread, but I had already removed the unneeded
compatible value locally, and was just waiting for the merge window and
holidays to end for sending the patch...

> > > >
> > > > ['arm,cortex-a7-timer', 'arm,armv7-timer'] is too long
> > > > 'arm,cortex-a7-timer' is not one of ['arm,armv7-timer', 'arm,armv8-timer']
> > > > 'arm,cortex-a7-timer' is not one of ['arm,cortex-a15-timer']
> > > >
> > > > Document this compatible to address it. The motivation to add this
> > > > change is taken from an already existing entry "arm,cortex-a15-timer".
> > > > Please note, this will not hurt any arch timer users.
> > >
> > > Eh, if it's never been documented or supported, I say just get rid of it.
> > > The arch timer interface is by definition part of a CPU, and we can tell
> > > what the CPU is by reading its ID registers. Indeed that's how the driver
> > > handles the non-zero number of CPU-specific errata that already exist - we
> > > don't need compatibles for that.
> > >
> > > In some ways it might have been nice to have *SoC-specific* compatibles
> > > given the difficulty some integrators seem to have had in wiring up a stable
> > > count *to* the interface, but it's not like they could be magically added to
> > > already-deployed DTs after a bug is discovered, and nor could we have
> > > mandated them from day 1 just in case and subsequently maintained a binding
> > > that is just an ever-growing list of every SoC. Oh well.
> >
> > Robin, A similar discussion was already done on v1 thread. Please see
> > below for details:
> > https://lore.kernel.org/linux-devicetree/20220317065925.GA9158@9a2d8922b8f1/
> > https://lore.kernel.org/linux-devicetree/726bde76-d792-febf-d364-6eedeb748c3b@canonical.com/
> >
> > And final outcome of discussion turns out to add this compatible string.
>
> I agree with Robin on dropping. More specific here is not useful. If
> we're going to add some cores, then we should add every core
> implementation.

... So consider it gone.

https://lore.kernel.org/r/a8e0cf00a983b4c539cdb1cfad5cc6b10b423c5b.1649680220.git.geert+renesas@glider.be/

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Kuldeep Singh]

Arch timer either require clock-frequency property or doesn't need to
specify clock at all in DT. In general, frequency can be determined
internally and in case of brokern firmwares, need to extend
clock-frequency to pass info to driver.

Aspeed BMC is the platform which defines clocks property, an invalid
entry which can be safely removed.

Moreover, clocks also matches incorrectly with the regex pattern.
Remove this entry altogether to fix it.
'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'

Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
---
 arch/arm/boot/dts/aspeed-g6.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index c32e87fad4dc..d5ef9aceb632 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -64,7 +64,6 @@ timer {
 			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
 			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
 			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
-		clocks = <&syscon ASPEED_CLK_HPLL>;
 		arm,cpu-registers-not-fw-configured;
 		always-on;
 	};
-- 
2.25.1

[PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Kuldeep Singh]

Arch timer either require clock-frequency property or doesn't need to
specify clock at all in DT. In general, frequency can be determined
internally and in case of brokern firmwares, need to extend
clock-frequency to pass info to driver.

Aspeed BMC is the platform which defines clocks property, an invalid
entry which can be safely removed.

Moreover, clocks also matches incorrectly with the regex pattern.
Remove this entry altogether to fix it.
'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'

Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
---
 arch/arm/boot/dts/aspeed-g6.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index c32e87fad4dc..d5ef9aceb632 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -64,7 +64,6 @@ timer {
 			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
 			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
 			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
-		clocks = <&syscon ASPEED_CLK_HPLL>;
 		arm,cpu-registers-not-fw-configured;
 		always-on;
 	};
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Marc Zyngier]

On Thu, 17 Mar 2022 19:15:26 +0000,
Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> 
> Arch timer either require clock-frequency property or doesn't need to
> specify clock at all in DT. In general, frequency can be determined
> internally and in case of brokern firmwares, need to extend
> clock-frequency to pass info to driver.

A clock frequency and a clock are not the same thing.

> 
> Aspeed BMC is the platform which defines clocks property, an invalid
> entry which can be safely removed.

Safely removed? Says who? Have you tested this change?

> 
> Moreover, clocks also matches incorrectly with the regex pattern.
> Remove this entry altogether to fix it.
> 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'

NAK. That's not a reason to randomly butcher things.

	M.

> 
> Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
> ---
>  arch/arm/boot/dts/aspeed-g6.dtsi | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
> index c32e87fad4dc..d5ef9aceb632 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -64,7 +64,6 @@ timer {
>  			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>  			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>  			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
> -		clocks = <&syscon ASPEED_CLK_HPLL>;
>  		arm,cpu-registers-not-fw-configured;
>  		always-on;
>  	};
> -- 
> 2.25.1
> 
> 

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Marc Zyngier]

On Thu, 17 Mar 2022 19:15:26 +0000,
Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> 
> Arch timer either require clock-frequency property or doesn't need to
> specify clock at all in DT. In general, frequency can be determined
> internally and in case of brokern firmwares, need to extend
> clock-frequency to pass info to driver.

A clock frequency and a clock are not the same thing.

> 
> Aspeed BMC is the platform which defines clocks property, an invalid
> entry which can be safely removed.

Safely removed? Says who? Have you tested this change?

> 
> Moreover, clocks also matches incorrectly with the regex pattern.
> Remove this entry altogether to fix it.
> 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'

NAK. That's not a reason to randomly butcher things.

	M.

> 
> Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com>
> ---
>  arch/arm/boot/dts/aspeed-g6.dtsi | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
> index c32e87fad4dc..d5ef9aceb632 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -64,7 +64,6 @@ timer {
>  			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>  			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>  			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
> -		clocks = <&syscon ASPEED_CLK_HPLL>;
>  		arm,cpu-registers-not-fw-configured;
>  		always-on;
>  	};
> -- 
> 2.25.1
> 
> 

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Kuldeep Singh]

On Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote:
> On Thu, 17 Mar 2022 19:15:26 +0000,
> Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> > 
> > Arch timer either require clock-frequency property or doesn't need to
> > specify clock at all in DT. In general, frequency can be determined
> > internally and in case of brokern firmwares, need to extend
> > clock-frequency to pass info to driver.
> 
> A clock frequency and a clock are not the same thing.

Yes Marc, That's what I have mentioned in commit description.

Driver uses "clock-frequency" property only and doesn't take inputs from
"clocks" property. So, any platform should refrain from defining such
entity at first place in DT. Binding also says the same i.e pass info
via "clock-frequency" property and no mention of "clocks".

> 
> > 
> > Aspeed BMC is the platform which defines clocks property, an invalid
> > entry which can be safely removed.
> 
> Safely removed? Says who? Have you tested this change?

Since "clocks" is never read by driver and driver incorporates
"clock-frequency" which was certainly not defined here, I believe this
reasoning is sufficient for my clause. As it's safe to remove an entry
which was never used.

Please note, it's just Aspeed BMC which had "clocks" defined, other
platforms which require input from DT have extended "clock-frequency"
property like I mentioned before.

I don't possess this platform physically,and did successfull compile
time testing. I have initally copied few Aspeed folks, they can help in
reviewing and confirming this.

> 
> > 
> > Moreover, clocks also matches incorrectly with the regex pattern.
> > Remove this entry altogether to fix it.
> > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'
> 
> NAK. That's not a reason to randomly butcher things.

I hope I explained my reasons above.

- Kuldeep

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Kuldeep Singh]

On Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote:
> On Thu, 17 Mar 2022 19:15:26 +0000,
> Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> > 
> > Arch timer either require clock-frequency property or doesn't need to
> > specify clock at all in DT. In general, frequency can be determined
> > internally and in case of brokern firmwares, need to extend
> > clock-frequency to pass info to driver.
> 
> A clock frequency and a clock are not the same thing.

Yes Marc, That's what I have mentioned in commit description.

Driver uses "clock-frequency" property only and doesn't take inputs from
"clocks" property. So, any platform should refrain from defining such
entity at first place in DT. Binding also says the same i.e pass info
via "clock-frequency" property and no mention of "clocks".

> 
> > 
> > Aspeed BMC is the platform which defines clocks property, an invalid
> > entry which can be safely removed.
> 
> Safely removed? Says who? Have you tested this change?

Since "clocks" is never read by driver and driver incorporates
"clock-frequency" which was certainly not defined here, I believe this
reasoning is sufficient for my clause. As it's safe to remove an entry
which was never used.

Please note, it's just Aspeed BMC which had "clocks" defined, other
platforms which require input from DT have extended "clock-frequency"
property like I mentioned before.

I don't possess this platform physically,and did successfull compile
time testing. I have initally copied few Aspeed folks, they can help in
reviewing and confirming this.

> 
> > 
> > Moreover, clocks also matches incorrectly with the regex pattern.
> > Remove this entry altogether to fix it.
> > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'
> 
> NAK. That's not a reason to randomly butcher things.

I hope I explained my reasons above.

- Kuldeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Marc Zyngier]

On Thu, 17 Mar 2022 21:10:24 +0000,
Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> 
> On Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote:
> > On Thu, 17 Mar 2022 19:15:26 +0000,
> > Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> > > 
> > > Arch timer either require clock-frequency property or doesn't need to
> > > specify clock at all in DT. In general, frequency can be determined
> > > internally and in case of brokern firmwares, need to extend
> > > clock-frequency to pass info to driver.
> > 
> > A clock frequency and a clock are not the same thing.
> 
> Yes Marc, That's what I have mentioned in commit description.
>
> Driver uses "clock-frequency" property only and doesn't take inputs from
> "clocks" property. So, any platform should refrain from defining such
> entity at first place in DT. Binding also says the same i.e pass info
> via "clock-frequency" property and no mention of "clocks".

And what do you think provides this clock frequency? Do you believe it
comes out of thin air? No, the driver doesn't use a clock, because it
*assumes* the clock feeding the counter is enabled at all times.

Does it mean such clock doesn't exist?

> 
> > 
> > > 
> > > Aspeed BMC is the platform which defines clocks property, an invalid
> > > entry which can be safely removed.
> > 
> > Safely removed? Says who? Have you tested this change?
> 
> Since "clocks" is never read by driver and driver incorporates
> "clock-frequency" which was certainly not defined here, I believe this
> reasoning is sufficient for my clause. As it's safe to remove an entry
> which was never used.

Really? And you have of course audited all possible firmware
implementations (the bootloader, for example, which would *enable*
this clock) and other operating systems than Linux that use the same
DT and run on the same HW?

The kernel tree unfortunately serves as a repository for all the DTs,
including for payloads other than Linux.

> Please note, it's just Aspeed BMC which had "clocks" defined, other
> platforms which require input from DT have extended "clock-frequency"
> property like I mentioned before.

Again: clock frequency and clock are not the same thing.

> I don't possess this platform physically,and did successfull compile
> time testing. I have initally copied few Aspeed folks, they can help in
> reviewing and confirming this.
> 
> > 
> > > 
> > > Moreover, clocks also matches incorrectly with the regex pattern.
> > > Remove this entry altogether to fix it.
> > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'
> > 
> > NAK. That's not a reason to randomly butcher things.
> 
> I hope I explained my reasons above.

My position on this sort of change remains. Blindly changing existing
DTs based on a warning provided by a tool that totally ignores the
reality of what is out there is not acceptable.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Marc Zyngier]

On Thu, 17 Mar 2022 21:10:24 +0000,
Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> 
> On Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote:
> > On Thu, 17 Mar 2022 19:15:26 +0000,
> > Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:
> > > 
> > > Arch timer either require clock-frequency property or doesn't need to
> > > specify clock at all in DT. In general, frequency can be determined
> > > internally and in case of brokern firmwares, need to extend
> > > clock-frequency to pass info to driver.
> > 
> > A clock frequency and a clock are not the same thing.
> 
> Yes Marc, That's what I have mentioned in commit description.
>
> Driver uses "clock-frequency" property only and doesn't take inputs from
> "clocks" property. So, any platform should refrain from defining such
> entity at first place in DT. Binding also says the same i.e pass info
> via "clock-frequency" property and no mention of "clocks".

And what do you think provides this clock frequency? Do you believe it
comes out of thin air? No, the driver doesn't use a clock, because it
*assumes* the clock feeding the counter is enabled at all times.

Does it mean such clock doesn't exist?

> 
> > 
> > > 
> > > Aspeed BMC is the platform which defines clocks property, an invalid
> > > entry which can be safely removed.
> > 
> > Safely removed? Says who? Have you tested this change?
> 
> Since "clocks" is never read by driver and driver incorporates
> "clock-frequency" which was certainly not defined here, I believe this
> reasoning is sufficient for my clause. As it's safe to remove an entry
> which was never used.

Really? And you have of course audited all possible firmware
implementations (the bootloader, for example, which would *enable*
this clock) and other operating systems than Linux that use the same
DT and run on the same HW?

The kernel tree unfortunately serves as a repository for all the DTs,
including for payloads other than Linux.

> Please note, it's just Aspeed BMC which had "clocks" defined, other
> platforms which require input from DT have extended "clock-frequency"
> property like I mentioned before.

Again: clock frequency and clock are not the same thing.

> I don't possess this platform physically,and did successfull compile
> time testing. I have initally copied few Aspeed folks, they can help in
> reviewing and confirming this.
> 
> > 
> > > 
> > > Moreover, clocks also matches incorrectly with the regex pattern.
> > > Remove this entry altogether to fix it.
> > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'
> > 
> > NAK. That's not a reason to randomly butcher things.
> 
> I hope I explained my reasons above.

My position on this sort of change remains. Blindly changing existing
DTs based on a warning provided by a tool that totally ignores the
reality of what is out there is not acceptable.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Joel Stanley]

On Thu, 17 Mar 2022 at 21:46, Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 17 Mar 2022 21:10:24 +0000,
> Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:

> > >
> > > >
> > > > Moreover, clocks also matches incorrectly with the regex pattern.
> > > > Remove this entry altogether to fix it.
> > > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'
> > >
> > > NAK. That's not a reason to randomly butcher things.
> >
> > I hope I explained my reasons above.
>
> My position on this sort of change remains. Blindly changing existing
> DTs based on a warning provided by a tool that totally ignores the
> reality of what is out there is not acceptable.

Thanks Marc for stating this. I share this view; we shouldn't go
around deleting parts of device trees for the sake of the bindings.
It's been happening across the tree, and I think it's to the detriment
of the supported hardware.

In the case of this particular change: I suspect this property was
there for early bringup, before the firmware was in place to configure
CNTFRQ. Looking back in time we had:

 clock-frequency = <25000000>;
 arm,cpu-registers-not-fw-configured;

I'm not sure why that changed from clock-frequency to clocks when the
device tree was mainlined.

That was bringup. These days, the vendor u-boot programs CNTFRQ with a
value for the system. This code is also in mainline u-boot, so as long
as you're running one of those firmwares the standard method will
work.

The qemu model also sets CNTFRQ, so loading the kernel without going
through u-boot will be fine there too.

Given that, I think we can go ahead with removing the property in this case.

Reviewed-by: Joel Stanley <joel@jms.id.au>

I'll take the patch through my aspeed tree.

Cheers,

Joel

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Joel Stanley]

On Thu, 17 Mar 2022 at 21:46, Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 17 Mar 2022 21:10:24 +0000,
> Kuldeep Singh <singh.kuldeep87k@gmail.com> wrote:

> > >
> > > >
> > > > Moreover, clocks also matches incorrectly with the regex pattern.
> > > > Remove this entry altogether to fix it.
> > > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'
> > >
> > > NAK. That's not a reason to randomly butcher things.
> >
> > I hope I explained my reasons above.
>
> My position on this sort of change remains. Blindly changing existing
> DTs based on a warning provided by a tool that totally ignores the
> reality of what is out there is not acceptable.

Thanks Marc for stating this. I share this view; we shouldn't go
around deleting parts of device trees for the sake of the bindings.
It's been happening across the tree, and I think it's to the detriment
of the supported hardware.

In the case of this particular change: I suspect this property was
there for early bringup, before the firmware was in place to configure
CNTFRQ. Looking back in time we had:

 clock-frequency = <25000000>;
 arm,cpu-registers-not-fw-configured;

I'm not sure why that changed from clock-frequency to clocks when the
device tree was mainlined.

That was bringup. These days, the vendor u-boot programs CNTFRQ with a
value for the system. This code is also in mainline u-boot, so as long
as you're running one of those firmwares the standard method will
work.

The qemu model also sets CNTFRQ, so loading the kernel without going
through u-boot will be fine there too.

Given that, I think we can go ahead with removing the property in this case.

Reviewed-by: Joel Stanley <joel@jms.id.au>

I'll take the patch through my aspeed tree.

Cheers,

Joel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Krzysztof Kozlowski]

On 17/03/2022 20:15, Kuldeep Singh wrote:
> 
> Moreover, clocks also matches incorrectly with the regex pattern.
> Remove this entry altogether to fix it.
> 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'

Except of ongoing discussion, this paragraph is incorrect.  There is no
incorrect match of regex pattern. The field is simply not documented in
the bindings (not allowed by bindings). This paragraph is actually
confusing and misleading.


Best regards,
Krzysztof

Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property

[Krzysztof Kozlowski]

On 17/03/2022 20:15, Kuldeep Singh wrote:
> 
> Moreover, clocks also matches incorrectly with the regex pattern.
> Remove this entry altogether to fix it.
> 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+'

Except of ongoing discussion, this paragraph is incorrect.  There is no
incorrect match of regex pattern. The field is simply not documented in
the bindings (not allowed by bindings). This paragraph is actually
confusing and misleading.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel