From: Jassi Brar <[email protected]>
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 <[email protected]>
---
.../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 <[email protected]>
+ - Jassi Brar <[email protected]>
+
+description:
+ Socionext SC2A11B (Synquacer) SoC based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - socionext,developer-box
+ - const: socionext,synquacer
+
+additionalProperties: true
+
+...
--
2.34.1
On 16/06/2023 05:58, [email protected] wrote:
> From: Jassi Brar <[email protected]>
>
> 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 16/06/2023 05:58, [email protected] wrote:
> From: Jassi Brar <[email protected]>
>
> 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 <[email protected]>
> ---
> .../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 <[email protected]>
> + - Jassi Brar <[email protected]>
> +
> +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
<[email protected]> wrote:
>
> On 16/06/2023 05:58, [email protected] wrote:
> > From: Jassi Brar <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > .../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 <[email protected]>
> > + - Jassi Brar <[email protected]>
> > +
> > +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
<[email protected]> wrote:
>
> On 16/06/2023 05:58, [email protected] wrote:
> > From: Jassi Brar <[email protected]>
> >
> > 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
> <[email protected]> wrote:
>>
>> On 16/06/2023 05:58, [email protected] wrote:
>>> From: Jassi Brar <[email protected]>
>>>
>>> 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
<[email protected]> wrote:
>
> On 16/06/2023 18:23, Jassi Brar wrote:
> > On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
> > <[email protected]> wrote:
> >>
> >> On 16/06/2023 05:58, [email protected] wrote:
> >>> From: Jassi Brar <[email protected]>
> >>>
> >>> 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
> <[email protected]> wrote:
>>
>> On 16/06/2023 18:23, Jassi Brar wrote:
>>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
>>> <[email protected]> wrote:
>>>>
>>>> On 16/06/2023 05:58, [email protected] wrote:
>>>>> From: Jassi Brar <[email protected]>
>>>>>
>>>>> 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
<[email protected]> wrote:
>
> On 16/06/2023 22:06, Jassi Brar wrote:
> > On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
> > <[email protected]> wrote:
> >>
> >> On 16/06/2023 18:23, Jassi Brar wrote:
> >>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
> >>> <[email protected]> wrote:
> >>>>
> >>>> On 16/06/2023 05:58, [email protected] wrote:
> >>>>> From: Jassi Brar <[email protected]>
> >>>>>
> >>>>> 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
> <[email protected]> wrote:
>>
>> On 16/06/2023 22:06, Jassi Brar wrote:
>>> On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
>>> <[email protected]> wrote:
>>>>
>>>> On 16/06/2023 18:23, Jassi Brar wrote:
>>>>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> On 16/06/2023 05:58, [email protected] wrote:
>>>>>>> From: Jassi Brar <[email protected]>
>>>>>>>
>>>>>>> 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
<[email protected]> wrote:
>
> On 17/06/2023 01:18, Jassi Brar wrote:
> > On Fri, 16 Jun 2023 at 15:34, Krzysztof Kozlowski
> > <[email protected]> wrote:
> >>
> >> On 16/06/2023 22:06, Jassi Brar wrote:
> >>> On Fri, 16 Jun 2023 at 11:47, Krzysztof Kozlowski
> >>> <[email protected]> wrote:
> >>>>
> >>>> On 16/06/2023 18:23, Jassi Brar wrote:
> >>>>> On Fri, 16 Jun 2023 at 05:15, Krzysztof Kozlowski
> >>>>> <[email protected]> wrote:
> >>>>>>
> >>>>>> On 16/06/2023 05:58, [email protected] wrote:
> >>>>>>> From: Jassi Brar <[email protected]>
> >>>>>>>
> >>>>>>> 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 <[email protected]>
Best regards,
Krzysztof
On Tue, 20 Jun 2023 at 11:50, Rob Herring <[email protected]> wrote:
>
> On Thu, Jun 15, 2023 at 10:58:13PM -0500, [email protected] wrote:
> > From: Jassi Brar <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > .../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 Thu, Jun 15, 2023 at 10:58:13PM -0500, [email protected] wrote:
> From: Jassi Brar <[email protected]>
>
> 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 <[email protected]>
> ---
> .../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?
From: Jassi Brar <[email protected]>
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 <[email protected]>
---
.../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 <[email protected]>
+ - Jassi Brar <[email protected]>
+
+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.1
On 20/06/2023 19:07, [email protected] wrote:
> From: Jassi Brar <[email protected]>
>
> 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 <[email protected]>
> ---
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 <[email protected]>
> + - Jassi Brar <[email protected]>
> +
> +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
From: Jassi Brar <[email protected]>
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 <[email protected]>
---
* 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 <[email protected]>
+ - Jassi Brar <[email protected]>
+
+description:
+ Socionext SC2A11B (Synquacer) SoC based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - socionext,developer-box
+ - const: socionext,synquacer
+
+additionalProperties: true
+
+...
--
2.34.1
On Wed, 21 Jun 2023 10:36:58 -0500, [email protected] wrote:
> From: Jassi Brar <[email protected]>
>
> 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 <[email protected]>
> ---
>
> * 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!