dt-bindings: arm: socionext: add bindings for the Synquacer platform

  From: Jassi Brar <jaswinder.singh@linaro.org>

Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
Specify bindings for the platform and boards based on that.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
---
 .../bindings/arm/socionext/synquacer.yaml     | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
  

On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
> From: Jassi Brar <jaswinder.singh@linaro.org>
> 
> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> Specify bindings for the platform and boards based on that.
> 
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> ---
>  .../bindings/arm/socionext/synquacer.yaml     | 28 +++++++++++++++++++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
> new file mode 100644
> index 000000000000..72554a4f1c92
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
> @@ -0,0 +1,28 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/socionext/synquacer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Socionext Synquacer platform
> +
> +maintainers:
> +  - Masahisa Kojima <masahisa.kojima@linaro.org>
> +  - Jassi Brar <jaswinder.singh@linaro.org>
> +
> +description:
> +  Socionext SC2A11B (Synquacer) SoC based boards
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - socionext,developer-box
> +          - const: socionext,synquacer

Last compatible looks very generic. Too generic. Are you sure it
uniquely identifies one specific SoC (not family, not generation, not
series)?

Best regards,
Krzysztof
  

On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
> From: Jassi Brar <jaswinder.singh@linaro.org>
> 
> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> Specify bindings for the platform and boards based on that.

A nit, subject: drop second/last, redundant "bindings". The
"dt-bindings" prefix is already stating that these are bindings.

> 

Binding without it's user is usually useless. Where is the user?

Best regards,
Krzysztof
  

On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
> > From: Jassi Brar <jaswinder.singh@linaro.org>
> >
> > Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> > Specify bindings for the platform and boards based on that.
> >
> > Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> > ---
> >  .../bindings/arm/socionext/synquacer.yaml     | 28 +++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
> > new file mode 100644
> > index 000000000000..72554a4f1c92
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
> > @@ -0,0 +1,28 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/socionext/synquacer.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Socionext Synquacer platform
> > +
> > +maintainers:
> > +  - Masahisa Kojima <masahisa.kojima@linaro.org>
> > +  - Jassi Brar <jaswinder.singh@linaro.org>
> > +
> > +description:
> > +  Socionext SC2A11B (Synquacer) SoC based boards
> > +
> > +properties:
> > +  $nodename:
> > +    const: '/'
> > +  compatible:
> > +    oneOf:
> > +      - items:
> > +          - enum:
> > +              - socionext,developer-box
> > +          - const: socionext,synquacer
>
> Last compatible looks very generic. Too generic. Are you sure it
> uniquely identifies one specific SoC (not family, not generation, not
> series)?
>
Yeah it does sound generic, but Synquacer and SC2A11B are
interchangeably used in s/w. And the dts in u-boot use this.
Kojima-san may have the final opinion.

thanks.
  

On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
> > From: Jassi Brar <jaswinder.singh@linaro.org>
> >
> > Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> > Specify bindings for the platform and boards based on that.
>
> A nit, subject: drop second/last, redundant "bindings". The
> "dt-bindings" prefix is already stating that these are bindings.
>
I can remove it, but I see many mentions like "Fix bindings for"  "Add
binding for" etc in the subject line.

>
> Binding without it's user is usually useless. Where is the user?
>
It is required for SystemReady-2.0 certification.

thanks
  

On 16/06/2023 18:23, Jassi Brar wrote:
> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
>>> From: Jassi Brar <jaswinder.singh@linaro.org>
>>>
>>> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
>>> Specify bindings for the platform and boards based on that.
>>
>> A nit, subject: drop second/last, redundant "bindings". The
>> "dt-bindings" prefix is already stating that these are bindings.
>>
> I can remove it, but I see many mentions like "Fix bindings for"  "Add
> binding for" etc in the subject line.

Can we fix them as well?


> 
>>
>> Binding without it's user is usually useless. Where is the user?
>>
> It is required for SystemReady-2.0 certification.

For what? If there is no user, it is not required for SR. We don't
document compatibles for something which does not exist in the projects.


Best regards,
Krzysztof
  

On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/06/2023 18:23, Jassi Brar wrote:
> > On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
> >>> From: Jassi Brar <jaswinder.singh@linaro.org>
> >>>
> >>> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> >>> Specify bindings for the platform and boards based on that.
> >>
> >> A nit, subject: drop second/last, redundant "bindings". The
> >> "dt-bindings" prefix is already stating that these are bindings.
> >>
> > I can remove it, but I see many mentions like "Fix bindings for"  "Add
> > binding for" etc in the subject line.
>
> Can we fix them as well?
>
??


> >
> >>
> >> Binding without it's user is usually useless. Where is the user?
> >>
> > It is required for SystemReady-2.0 certification.
>
> For what? If there is no user, it is not required for SR. We don't
> document compatibles for something which does not exist in the projects.
>
The dts/dtsi for synquacer will be added later.
I am sure you are aware that there are countless bindings without
actual use in any dts/dtsi. When exactly did it become mandatory to
have dts/dtsi for the bindings to be merged upstream?

-j
  

On 16/06/2023 22:06, Jassi Brar wrote:
> On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 16/06/2023 18:23, Jassi Brar wrote:
>>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
>>>>> From: Jassi Brar <jaswinder.singh@linaro.org>
>>>>>
>>>>> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
>>>>> Specify bindings for the platform and boards based on that.
>>>>
>>>> A nit, subject: drop second/last, redundant "bindings". The
>>>> "dt-bindings" prefix is already stating that these are bindings.
>>>>
>>> I can remove it, but I see many mentions like "Fix bindings for"  "Add
>>> binding for" etc in the subject line.
>>
>> Can we fix them as well?
>>
> ??

What else I can say to such argument?

> 
> 
>>>
>>>>
>>>> Binding without it's user is usually useless. Where is the user?
>>>>
>>> It is required for SystemReady-2.0 certification.
>>
>> For what? If there is no user, it is not required for SR. We don't
>> document compatibles for something which does not exist in the projects.
>>
> The dts/dtsi for synquacer will be added later.
> I am sure you are aware that there are countless bindings without
> actual use in any dts/dtsi.

Bindings without user (so no DTSI and no driver)? Just few, not countless.

> When exactly did it become mandatory to
> have dts/dtsi for the bindings to be merged upstream?

It was always. We do not want/need to document downstream stuff or
anything  just because it is somewhere there.

Best regards,
Krzysztof
  

On Fri, 16 Jun 2023 at 15:34, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/06/2023 22:06, Jassi Brar wrote:
> > On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 16/06/2023 18:23, Jassi Brar wrote:
> >>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
> >>>>> From: Jassi Brar <jaswinder.singh@linaro.org>
> >>>>>
> >>>>> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> >>>>> Specify bindings for the platform and boards based on that.
> >>>>
> >>>> A nit, subject: drop second/last, redundant "bindings". The
> >>>> "dt-bindings" prefix is already stating that these are bindings.
> >>>>
> >>> I can remove it, but I see many mentions like "Fix bindings for"  "Add
> >>> binding for" etc in the subject line.
> >>
> >> Can we fix them as well?
> >>
> > ??
> What else I can say to such argument?
>
It was not an argument, I agreed to remove it. I just observed that
the nit-pick was arbitrary.
And frankly
   "dt-bindings: arm: socionext: add Synquacer"   is as misleading as
   "dt-bindings: arm: socionext: add bindings for the Synquacer"   is improper.


> >>>>
> >>>> Binding without it's user is usually useless. Where is the user?
> >>>>
> >>> It is required for SystemReady-2.0 certification.
> >>
> >> For what? If there is no user, it is not required for SR. We don't
> >> document compatibles for something which does not exist in the projects.
> >>
> > The dts/dtsi for synquacer will be added later.
> > I am sure you are aware that there are countless bindings without
> > actual use in any dts/dtsi.
>
> Bindings without user (so no DTSI and no driver)? Just few, not countless.
>
I disagree. But I don't have time to write a script to find
compatibles/enums and properties in yaml/txt files that are not in any
dts/dtsi file.
 By that logic synquacer's spi/netsec/i2c/exiu bindings and drivers in
kernel are illegit too?

Also the user may not be in Linux, but we keep "os-agnostic" bindings in Linux.
The synquacer dts/dtsi are in u-boot upstream. SR testsuite looks up
the underlying platform name and checks if the bindings are merged
upstream.
While I am not against also submitting dts/dtsi in linux, I don't
think the binding should be held at ransom.

> > When exactly did it become mandatory to
> > have dts/dtsi for the bindings to be merged upstream?
>
> It was always. We do not want/need to document downstream stuff or
> anything  just because it is somewhere there.
>
I am not asking you to merge an obscure internal revision of some SoC.
Synquacer is a public development platform and a "96board" already
certified for SR-1.0.

thnx.
  

On 17/06/2023 01:18, Jassi Brar wrote:
> On Fri, 16 Jun 2023 at 15:34, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 16/06/2023 22:06, Jassi Brar wrote:
>>> On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 16/06/2023 18:23, Jassi Brar wrote:
>>>>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
>>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>>
>>>>>> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
>>>>>>> From: Jassi Brar <jaswinder.singh@linaro.org>
>>>>>>>
>>>>>>> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
>>>>>>> Specify bindings for the platform and boards based on that.
>>>>>>
>>>>>> A nit, subject: drop second/last, redundant "bindings". The
>>>>>> "dt-bindings" prefix is already stating that these are bindings.
>>>>>>
>>>>> I can remove it, but I see many mentions like "Fix bindings for"  "Add
>>>>> binding for" etc in the subject line.
>>>>
>>>> Can we fix them as well?
>>>>
>>> ??
>> What else I can say to such argument?
>>
> It was not an argument, I agreed to remove it. I just observed that
> the nit-pick was arbitrary.
> And frankly
>    "dt-bindings: arm: socionext: add Synquacer"   is as misleading as
>    "dt-bindings: arm: socionext: add bindings for the Synquacer"   is improper.

"add Synquacer boards"
it is both precise and correct. No misleading.


> 
> 
>>>>>>
>>>>>> Binding without it's user is usually useless. Where is the user?
>>>>>>
>>>>> It is required for SystemReady-2.0 certification.
>>>>
>>>> For what? If there is no user, it is not required for SR. We don't
>>>> document compatibles for something which does not exist in the projects.
>>>>
>>> The dts/dtsi for synquacer will be added later.
>>> I am sure you are aware that there are countless bindings without
>>> actual use in any dts/dtsi.
>>
>> Bindings without user (so no DTSI and no driver)? Just few, not countless.
>>
> I disagree. But I don't have time to write a script to find
> compatibles/enums and properties in yaml/txt files that are not in any
> dts/dtsi file.
>  By that logic synquacer's spi/netsec/i2c/exiu bindings and drivers in
> kernel are illegit too?

Don't know which one you talk about.

> 
> Also the user may not be in Linux, but we keep "os-agnostic" bindings in Linux.

I did not say anything about Linux here. Look:

"does not exist in the projects."

> The synquacer dts/dtsi are in u-boot upstream. SR testsuite looks up

Sure, can you point it? U-Boot upstream is a valid project. Just like
many other upstream ones.

> the underlying platform name and checks if the bindings are merged
> upstream.
> While I am not against also submitting dts/dtsi in linux, I don't
> think the binding should be held at ransom.
> 
>>> When exactly did it become mandatory to
>>> have dts/dtsi for the bindings to be merged upstream?
>>
>> It was always. We do not want/need to document downstream stuff or
>> anything  just because it is somewhere there.
>>
> I am not asking you to merge an obscure internal revision of some SoC.
> Synquacer is a public development platform and a "96board" already
> certified for SR-1.0.

Without any reference to any project using this, it looks like you are.
Sorry.

Best regards,
Krzysztof
  

On Sat, 17 Jun 2023 at 02:18, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 17/06/2023 01:18, Jassi Brar wrote:
> > On Fri, 16 Jun 2023 at 15:34, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 16/06/2023 22:06, Jassi Brar wrote:
> >>> On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 16/06/2023 18:23, Jassi Brar wrote:
> >>>>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
> >>>>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>>>
> >>>>>> On 16/06/2023 05:58, jaswinder.singh@linaro.org wrote:
> >>>>>>> From: Jassi Brar <jaswinder.singh@linaro.org>
> >>>>>>>
> >>>>>>> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> >>>>>>> Specify bindings for the platform and boards based on that.
> >>>>>>
> >>>>>> A nit, subject: drop second/last, redundant "bindings". The
> >>>>>> "dt-bindings" prefix is already stating that these are bindings.
> >>>>>>
> >>>>> I can remove it, but I see many mentions like "Fix bindings for"  "Add
> >>>>> binding for" etc in the subject line.
> >>>>
> >>>> Can we fix them as well?
> >>>>
> >>> ??
> >> What else I can say to such argument?
> >>
> > It was not an argument, I agreed to remove it. I just observed that
> > the nit-pick was arbitrary.
> > And frankly
> >    "dt-bindings: arm: socionext: add Synquacer"   is as misleading as
> >    "dt-bindings: arm: socionext: add bindings for the Synquacer"   is improper.
>
> "add Synquacer boards"
> it is both precise and correct. No misleading.
>
Ok. I am going to do that. Are you going to enforce this practice for
all submissions in future?


> >>
> >> Bindings without user (so no DTSI and no driver)? Just few, not countless.
> >>
> > I disagree. But I don't have time to write a script to find
> > compatibles/enums and properties in yaml/txt files that are not in any
> > dts/dtsi file.
> >  By that logic synquacer's spi/netsec/i2c/exiu bindings and drivers in
> > kernel are illegit too?
>
> Don't know which one you talk about.
>
Documentation/devicetree/bindings/
  {
     i2c/socionext,synquacer-i2c.yaml
     interrupt-controller/socionext,synquacer-exiu.yaml
     net/socionext,synquacer-netsec.yaml
     spi/socionext,synquacer-spi.yaml
   }
and corresponding code in drivers/


> > The synquacer dts/dtsi are in u-boot upstream. SR testsuite looks up
>
> Sure, can you point it? U-Boot upstream is a valid project. Just like
> many other upstream ones.
>
Location of dts/dtsi in u-boot upstream is
     https://elixir.bootlin.com/u-boot/latest/source/arch/arm/dts
see { synquacer-sc2a11-caches.dtsi     synquacer-sc2a11.dtsi
synquacer-sc2a11-developerbox-u-boot.dtsi
synquacer-sc2a11-developerbox.dts }

regards.
  

On 19/06/2023 21:17, Jassi Brar wrote:
>>>>>> Can we fix them as well?
>>>>>>
>>>>> ??
>>>> What else I can say to such argument?
>>>>
>>> It was not an argument, I agreed to remove it. I just observed that
>>> the nit-pick was arbitrary.
>>> And frankly
>>>    "dt-bindings: arm: socionext: add Synquacer"   is as misleading as
>>>    "dt-bindings: arm: socionext: add bindings for the Synquacer"   is improper.
>>
>> "add Synquacer boards"
>> it is both precise and correct. No misleading.
>>
> Ok. I am going to do that. Are you going to enforce this practice for
> all submissions in future?

How many cases can you find that I did not enforce it? That I provided a
review and accepted other subject? It's nothing new...

> 
> 
>>>>
>>>> Bindings without user (so no DTSI and no driver)? Just few, not countless.
>>>>
>>> I disagree. But I don't have time to write a script to find
>>> compatibles/enums and properties in yaml/txt files that are not in any
>>> dts/dtsi file.
>>>  By that logic synquacer's spi/netsec/i2c/exiu bindings and drivers in
>>> kernel are illegit too?
>>
>> Don't know which one you talk about.
>>
> Documentation/devicetree/bindings/
>   {
>      i2c/socionext,synquacer-i2c.yaml

There is a user. What do you want to prove with this one?

>      interrupt-controller/socionext,synquacer-exiu.yaml
>      net/socionext,synquacer-netsec.yaml
>      spi/socionext,synquacer-spi.yaml
>    }
> and corresponding code in drivers/
> 
> 
>>> The synquacer dts/dtsi are in u-boot upstream. SR testsuite looks up
>>
>> Sure, can you point it? U-Boot upstream is a valid project. Just like
>> many other upstream ones.
>>
> Location of dts/dtsi in u-boot upstream is
>      https://elixir.bootlin.com/u-boot/latest/source/arch/arm/dts


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof
  

On Thu, Jun 15, 2023 at 10:58:13PM -0500, jaswinder.singh@linaro.org wrote:
> From: Jassi Brar <jaswinder.singh@linaro.org>
> 
> Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> Specify bindings for the platform and boards based on that.
> 
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> ---
>  .../bindings/arm/socionext/synquacer.yaml     | 28 +++++++++++++++++++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/socionext/synquacer.yaml

Should I pick this up or Socionext maintainers will?
  

On Tue, 20 Jun 2023 at 11:50, Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Jun 15, 2023 at 10:58:13PM -0500, jaswinder.singh@linaro.org wrote:
> > From: Jassi Brar <jaswinder.singh@linaro.org>
> >
> > Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer).
> > Specify bindings for the platform and boards based on that.
> >
> > Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> > ---
> >  .../bindings/arm/socionext/synquacer.yaml     | 28 +++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
>
> Should I pick this up or Socionext maintainers will?
>
Please consider Patch-v2 that changes the subject line and specifies
the SoC compatible 'sc2a11b' (Synquacer is the brand name).

Thanks

-jassi