.../bindings/arm/socionext/synquacer.yaml | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
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
+
+additionalProperties: true
+
+...
--
2.34.1On 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
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. > > 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 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 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.
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 | 29 +++++++++++++++++++
1 file changed, 29 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..c582d9c31213
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
@@ -0,0 +1,29 @@
+# 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
+ - socionext,synquacer
+ - const: socionext,sc2a11b
+
+additionalProperties: true
+
+...
--
2.34.1On 20/06/2023 19:07, 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> > --- Attach changelog after ---. > .../bindings/arm/socionext/synquacer.yaml | 29 +++++++++++++++++++ > 1 file changed, 29 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..c582d9c31213 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml > @@ -0,0 +1,29 @@ > +# 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 > + - socionext,synquacer > + - const: socionext,sc2a11b That's quite different change. What is synquacer in this case? You claim now it is a board, but based on previous discussions and U-Boot source it does not look like such. What's more, it does not match U-Boot sources and there is no Linux user of this, so it contradicts points of our previous discussion. Best regards, Krzysztof
On Tue, 20 Jun 2023 at 12:16, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 20/06/2023 19:07, 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> > > --- > > Attach changelog after ---. > > > .../bindings/arm/socionext/synquacer.yaml | 29 +++++++++++++++++++ > > 1 file changed, 29 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..c582d9c31213 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml > > @@ -0,0 +1,29 @@ > > +# 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 > > + - socionext,synquacer > > + - const: socionext,sc2a11b > > That's quite different change. > So it is not carrying your ack. > What is synquacer in this case? You claim > now it is a board, but based on previous discussions and U-Boot source > it does not look like such. > I never made that claim. I said Kojima-san will confirm. He informed Synquacer is a brand name. Currently no code internally or externally differentiates between SC2A11B and Synquacer and we might as well keep living with Synquacer only. This patch is an attempt to be accurate. -j
On 20/06/2023 19:24, Jassi Brar wrote: >>> +properties: >>> + $nodename: >>> + const: '/' >>> + compatible: >>> + oneOf: >>> + - items: >>> + - enum: >>> + - socionext,developer-box >>> + - socionext,synquacer >>> + - const: socionext,sc2a11b >> >> That's quite different change. >> > So it is not carrying your ack. > >> What is synquacer in this case? You claim >> now it is a board, but based on previous discussions and U-Boot source >> it does not look like such. >> > I never made that claim. I said Kojima-san will confirm. He informed > Synquacer is a brand name. > > Currently no code internally or externally differentiates between > SC2A11B and Synquacer and we might as well keep living with Synquacer > only. This patch is an attempt to be accurate. Then the patch is not correct, because synquacer is not a board. We should anyway choose only one for adding to documentation. Best regards, Krzysztof
On Tue, 20 Jun 2023 at 12:54, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 20/06/2023 19:24, Jassi Brar wrote: > >>> +properties: > >>> + $nodename: > >>> + const: '/' > >>> + compatible: > >>> + oneOf: > >>> + - items: > >>> + - enum: > >>> + - socionext,developer-box > >>> + - socionext,synquacer > >>> + - const: socionext,sc2a11b > >> > >> That's quite different change. > >> > > So it is not carrying your ack. > > > >> What is synquacer in this case? You claim > >> now it is a board, but based on previous discussions and U-Boot source > >> it does not look like such. > >> > > I never made that claim. I said Kojima-san will confirm. He informed > > Synquacer is a brand name. > > > > Currently no code internally or externally differentiates between > > SC2A11B and Synquacer and we might as well keep living with Synquacer > > only. This patch is an attempt to be accurate. > > Then the patch is not correct, because synquacer is not a board. We > should anyway choose only one for adding to documentation. > OK. I will revert to using the brand name Synquacer. thnkx
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>
---
* Revert back to using the brand name Synquacer instead of sc2a11b
.../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
+
+additionalProperties: true
+
+...
--
2.34.1On Wed, 21 Jun 2023 10:36:58 -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> > --- > > * Revert back to using the brand name Synquacer instead of sc2a11b > > .../bindings/arm/socionext/synquacer.yaml | 28 +++++++++++++++++++ > 1 file changed, 28 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/socionext/synquacer.yaml > Applied, thanks!
© 2016 - 2026 Red Hat, Inc.