Re: dtbs_check issue

Re: dtbs_check issue

[Lad, Prabhakar]

+CC devicetree@vger.kernel.org.

On Thu, Jul 21, 2022 at 4:07 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> Hi,
>
> We have the below entries in renesas.yaml in arm directory [0]
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/renesas.yaml?h=next-20220721#n418
>
>       - description: RZ/G2UL (R9A07G043)
>         items:
>           - enum:
>               - renesas,smarc-evk # SMARC EVK
>           - enum:
>               - renesas,r9a07g043u11 # RZ/G2UL Type-1
>               - renesas,r9a07g043u12 # RZ/G2UL Type-2
>           - const: renesas,r9a07g043
>
>       - description: RZ/G2{L,LC} (R9A07G044)
>         items:
>           - enum:
>               - renesas,smarc-evk # SMARC EVK
>           - enum:
>               - renesas,r9a07g044c1 # Single Cortex-A55 RZ/G2LC
>               - renesas,r9a07g044c2 # Dual Cortex-A55 RZ/G2LC
>               - renesas,r9a07g044l1 # Single Cortex-A55 RZ/G2L
>               - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L
>           - const: renesas,r9a07g044
>
>       - description: RZ/V2L (R9A07G054)
>         items:
>           - enum:
>               - renesas,smarc-evk # SMARC EVK
>           - enum:
>               - renesas,r9a07g054l1 # Single Cortex-A55 RZ/V2L
>               - renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L
>           - const: renesas,r9a07g054
>
> I have added a new schema renesas.yaml [1] in
> Documentation/devicetree/bindings/riscv/ folder for Renesas RISV
> SoC's.
>
> [1] https://paste.debian.net/1247954/
>
> properties:
>   $nodename:
>     const: '/'
>   compatible:
>     oneOf:
>       - description: RZ/Five (R9A07G043)
>         items:
>           - enum:
>               - renesas,smarc-evk # SMARC EVK
>           - const: renesas,r9a07g043f1
>           - const: renesas,r9a07g043
>
> additionalProperties: true
>
> -----------------x----------------------------x----------------------
>
> I have the DTS arch/riscv/boot/dts/renesas/r9a07g043-smarc.dts with
> below property:
>                           compatible = "renesas,smarc-evk",
> "renesas,r9a07g043f1", "renesas,r9a07g043";
>
> And when I run the dtbs_check I get the below error:
>
> prasmi@prasmi:~/work/linux$ make ARCH=riscv
> CROSS_COMPILE=riscv64-linux-gnu- dtbs_check
>   LINT    Documentation/devicetree/bindings
>   CHKDT   Documentation/devicetree/bindings/processed-schema.json
>   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
>   DTC     arch/riscv/boot/dts/renesas/r9a07g043-smarc.dtb
>   CHECK   arch/riscv/boot/dts/renesas/r9a07g043-smarc.dtb
> /home/prasmi/work/linux/arch/riscv/boot/dts/renesas/r9a07g043-smarc.dtb:
> /: compatible: 'oneOf' conditional failed, one must be fixed:
>     ['renesas,smarc-evk', 'renesas,r9a07g043f1', 'renesas,r9a07g043']
> is too long
>     /home/prasmi/work/linux/arch/riscv/boot/dts/renesas/r9a07g043-smarc.dtb:
> /: compatible: 'oneOf' conditional failed, one must be fixed:
>         ['renesas,smarc-evk', 'renesas,r9a07g043f1',
> 'renesas,r9a07g043'] is too short
>         'shimafuji,kingfisher' was expected
>         'renesas,r9a07g043f1' is not one of ['renesas,h3ulcb',
> 'renesas,m3ulcb', 'renesas,m3nulcb']
>         'renesas,r9a07g043' is not one of ['renesas,r8a7795',
> 'renesas,r8a7796', 'renesas,r8a77961', 'renesas,r8a77965']
>         'renesas,r9a07g043' is not one of ['renesas,r8a779m0',
> 'renesas,r8a779m1', 'renesas,r8a779m2', 'renesas,r8a779m3',
> 'renesas,r8a779m4', 'renesas,r8a779m5', 'renesas,r8a779m8']
>     'renesas,smarc-evk' is not one of ['renesas,kzm9d']
>     'renesas,smarc-evk' is not one of ['renesas,genmai',
> 'renesas,gr-peach', 'renesas,rskrza1']
>     'renesas,smarc-evk' is not one of ['renesas,rza2mevb']
>     'renesas,smarc-evk' is not one of ['renesas,kzm9g']
>     'renesas,smarc-evk' is not one of ['renesas,ape6evm']
>     'renesas,smarc-evk' is not one of ['renesas,armadillo800eva']
>     'renesas,smarc-evk' is not one of ['iwave,g21m']
>     'renesas,smarc-evk' is not one of ['iwave,g21d']
>     'renesas,smarc-evk' is not one of ['iwave,g20d']
>     'renesas,smarc-evk' is not one of ['iwave,g20m', 'renesas,sk-rzg1m']
>     'renesas,smarc-evk' is not one of ['iwave,g20m']
>     'renesas,smarc-evk' is not one of ['iwave,g22m', 'renesas,sk-rzg1e']
>     'iwave,g22d' was expected
>     'renesas,smarc-evk' is not one of ['iwave,g23s']
>     'renesas,smarc-evk' is not one of ['hoperun,hihope-rzg2m',
> 'beacon,beacon-rzg2m']
>     'renesas,smarc-evk' is not one of ['hoperun,hihope-rzg2-ex']
>     'renesas,smarc-evk' is not one of ['beacon,beacon-rzg2n',
> 'hoperun,hihope-rzg2n']
>     'renesas,smarc-evk' is not one of ['si-linux,cat874']
>     'renesas,smarc-evk' is not one of ['si-linux,cat875']
>     'renesas,smarc-evk' is not one of ['beacon,beacon-rzg2h',
> 'hoperun,hihope-rzg2h']
>     'renesas,smarc-evk' is not one of ['renesas,bockw']
>     'renesas,smarc-evk' is not one of ['renesas,marzen']
>     'renesas,smarc-evk' is not one of ['renesas,lager', 'renesas,stout']
>     'renesas,smarc-evk' is not one of ['renesas,henninger',
> 'renesas,koelsch', 'renesas,porter']
>     'renesas,smarc-evk' is not one of ['renesas,blanche', 'renesas,wheat']
>     'renesas,smarc-evk' is not one of ['renesas,gose']
>     'renesas,smarc-evk' is not one of ['renesas,alt', 'renesas,silk']
>     'renesas,smarc-evk' is not one of ['renesas,h3ulcb',
> 'renesas,salvator-x', 'renesas,salvator-xs']
>     'renesas,smarc-evk' is not one of ['renesas,m3ulcb',
> 'renesas,salvator-x', 'renesas,salvator-xs']
>     'renesas,smarc-evk' is not one of ['renesas,m3ulcb', 'renesas,salvator-xs']
>     'renesas,smarc-evk' is not one of ['renesas,m3nulcb',
> 'renesas,salvator-x', 'renesas,salvator-xs']
>     'renesas,smarc-evk' is not one of ['renesas,eagle', 'renesas,v3msk']
>     'renesas,smarc-evk' is not one of ['renesas,condor', 'renesas,v3hsk']
>     'renesas,smarc-evk' is not one of ['renesas,ebisu']
>     'renesas,smarc-evk' is not one of ['renesas,draak']
>     'renesas,smarc-evk' is not one of ['renesas,falcon-cpu']
>     'renesas,smarc-evk' is not one of ['renesas,falcon-breakout']
>     'renesas,smarc-evk' is not one of ['renesas,spider-cpu']
>     'renesas,smarc-evk' is not one of ['renesas,spider-breakout']
>     'renesas,smarc-evk' is not one of ['renesas,white-hawk-cpu']
>     'renesas,smarc-evk' is not one of ['renesas,white-hawk-breakout']
>     'renesas,smarc-evk' is not one of ['renesas,h3ulcb', 'renesas,salvator-xs']
>     'renesas,smarc-evk' is not one of ['renesas,m3nulcb', 'renesas,salvator-xs']
>     'renesas,smarc-evk' is not one of ['renesas,rzn1d400-db']
>     'renesas,smarc-evk' is not one of ['renesas,rzv2mevk2']
>     'renesas,emev2' was expected
>     'renesas,r7s72100' was expected
>     'renesas,r7s9210' was expected
>     'renesas,sh73a0' was expected
>     'renesas,r8a73a4' was expected
>     'renesas,r8a7740' was expected
>     'renesas,r8a7742' was expected
>     'iwave,g21m' was expected
>     'iwave,g20m' was expected
>     'renesas,r8a7743' was expected
>     'renesas,r8a7744' was expected
>     'renesas,r8a7745' was expected
>     'iwave,g22m' was expected
>     'renesas,r8a77470' was expected
>     'renesas,r8a774a1' was expected
>     'hoperun,hihope-rzg2m' was expected
>     'renesas,r8a774b1' was expected
>     'hoperun,hihope-rzg2n' was expected
>     'renesas,r8a774c0' was expected
>     'si-linux,cat874' was expected
>     'renesas,r8a774e1' was expected
>     'hoperun,hihope-rzg2h' was expected
>     'renesas,r8a7778' was expected
>     'renesas,r8a7779' was expected
>     'renesas,r8a7790' was expected
>     'renesas,r8a7791' was expected
>     'renesas,r8a7792' was expected
>     'renesas,r8a7793' was expected
>     'renesas,r8a7794' was expected
>     'renesas,r8a7795' was expected
>     'renesas,r8a7796' was expected
>     'renesas,r8a77961' was expected
>     'renesas,r8a77965' was expected
>     'renesas,r8a77970' was expected
>     'renesas,r8a77980' was expected
>     'renesas,r8a77990' was expected
>     'renesas,r8a77995' was expected
>     'renesas,r8a779a0' was expected
>     'renesas,falcon-cpu' was expected
>     'renesas,r8a779f0' was expected
>     'renesas,spider-cpu' was expected
>     'renesas,r8a779g0' was expected
>     'renesas,white-hawk-cpu' was expected
>     'renesas,r8a779m0' was expected
>     'renesas,r8a779m1' was expected
>     'renesas,r8a779m2' was expected
>     'renesas,r8a779m3' was expected
>     'renesas,r8a779m4' was expected
>     'renesas,r8a779m5' was expected
>     'renesas,r8a779m6' was expected
>     'renesas,r8a779m7' was expected
>     'renesas,r8a779m8' was expected
>     'renesas,r9a06g032' was expected
>     'renesas,r9a07g043f1' is not one of ['renesas,r9a07g043u11',
> 'renesas,r9a07g043u12']
>     'renesas,r9a07g043f1' is not one of ['renesas,r9a07g044c1',
> 'renesas,r9a07g044c2', 'renesas,r9a07g044l1', 'renesas,r9a07g044l2']
>     'renesas,r9a07g043f1' is not one of ['renesas,r9a07g054l1',
> 'renesas,r9a07g054l2']
>     'renesas,r9a09g011' was expected
>     'renesas,r9a07g044' was expected
>     'renesas,r9a07g054' was expected
>     From schema:
> /home/prasmi/work/linux/Documentation/devicetree/bindings/arm/renesas.yaml
>
> And this is strangely coming from the arm renesas.yaml schema.
>
> -----------------x----------------------------x----------------------
>
> Now when I remove all the SMARC boards from arm renesas.yaml schema,
> dtbs_check passes through successfully.
>
>       - description: RZ/G2UL (R9A07G043)
>         items:
>           - enum:
>               - renesas,smarc-evk # SMARC EVK
>           - enum:
>               - renesas,r9a07g043u11 # RZ/G2UL Type-1
>               - renesas,r9a07g043u12 # RZ/G2UL Type-2
>           - const: renesas,r9a07g043
>
>       - description: RZ/G2{L,LC} (R9A07G044)
>         items:
>           - enum:
>               - renesas,smarc-evk # SMARC EVK
>           - enum:
>               - renesas,r9a07g044c1 # Single Cortex-A55 RZ/G2LC
>               - renesas,r9a07g044c2 # Dual Cortex-A55 RZ/G2LC
>               - renesas,r9a07g044l1 # Single Cortex-A55 RZ/G2L
>               - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L
>           - const: renesas,r9a07g044
>
>       - description: RZ/V2L (R9A07G054)
>         items:
>           - enum:
>               - renesas,smarc-evk # SMARC EVK
>           - enum:
>               - renesas,r9a07g054l1 # Single Cortex-A55 RZ/V2L
>               - renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L
>           - const: renesas,r9a07g054
>
> Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> dtbs_check failures.
>
> Any pointers on how I can get around this issue?
>
> Cheers,
> Prabhakar

Re: dtbs_check issue

[Lad, Prabhakar]

Hi Krzysztof,

On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > dtbs_check failures.
> >
> > Any pointers on how I can get around this issue?
>
> Few months ago:
> https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
>
Thanks for the link.

> Although Rob admitted in the thread this is in general allowed
> configuration, to me it is still confusing - the left-most compatible is
> not the most specific. Non obvious, confusing and it seems dtschema does
> not support it?
>
It looks like dtschema does not support it.

Cheers,
Prabhakar

Re: dtbs_check issue

[Rob Herring]

On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> Hi Krzysztof,
>
> On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > dtbs_check failures.
> > >
> > > Any pointers on how I can get around this issue?
> >
> > Few months ago:
> > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> >
> Thanks for the link.
>
> > Although Rob admitted in the thread this is in general allowed
> > configuration, to me it is still confusing - the left-most compatible is
> > not the most specific. Non obvious, confusing and it seems dtschema does
> > not support it?
> >
> It looks like dtschema does not support it.

The issue is the same as licensed IP where we have a generic
compatible and per licensee compatibles in separate schemas. The
solution anytime a compatible exists in more than 1 schema is a custom
'select' which excludes that compatible. That would be messy here
though due to the large number of compatibles. Perhaps we could
instead merge a custom select with the default generated one. Then the
schema would just need:

select:
  not:
    properties:
      contains:
        const: renesas,smarc-evk

We'd have to figure out when to merge or not merge. Maybe only merge a
'not' schema.


The other way to solve this is simply not having 2 schema files. Why
do we have SoC/board schemas under a CPU arch directory? There's
nothing architecture specific about them (I have the same opinion on
.dts files too). So I'd be in favor of putting all root node schemas
in one directory.

Rob

Re: dtbs_check issue

[Lad, Prabhakar]

Hi Rob,

On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
> >
> > Hi Krzysztof,
> >
> > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> > >
> > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > dtbs_check failures.
> > > >
> > > > Any pointers on how I can get around this issue?
> > >
> > > Few months ago:
> > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > >
> > Thanks for the link.
> >
> > > Although Rob admitted in the thread this is in general allowed
> > > configuration, to me it is still confusing - the left-most compatible is
> > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > not support it?
> > >
> > It looks like dtschema does not support it.
>
> The issue is the same as licensed IP where we have a generic
> compatible and per licensee compatibles in separate schemas. The
> solution anytime a compatible exists in more than 1 schema is a custom
> 'select' which excludes that compatible. That would be messy here
> though due to the large number of compatibles. Perhaps we could
> instead merge a custom select with the default generated one. Then the
> schema would just need:
>
> select:
>   not:
>     properties:
>       contains:
>         const: renesas,smarc-evk
>
> We'd have to figure out when to merge or not merge. Maybe only merge a
> 'not' schema.
>
Agreed with this approach the select list might keep growing.

>
> The other way to solve this is simply not having 2 schema files. Why
> do we have SoC/board schemas under a CPU arch directory? There's
> nothing architecture specific about them (I have the same opinion on
> .dts files too). So I'd be in favor of putting all root node schemas
> in one directory.
>
Agreed, but what do we name the directory which has root node schemas?

Geert, are you ok with moving the schema out and having a single file
for all the Renesas SoC'/Boards?

Cheers,
Prabhakar

Re: dtbs_check issue

[Rob Herring]

On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> Hi Rob,
>
> On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> > <prabhakar.csengg@gmail.com> wrote:
> > >
> > > Hi Krzysztof,
> > >
> > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > > <krzysztof.kozlowski@linaro.org> wrote:
> > > >
> > > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > > dtbs_check failures.
> > > > >
> > > > > Any pointers on how I can get around this issue?
> > > >
> > > > Few months ago:
> > > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > > >
> > > Thanks for the link.
> > >
> > > > Although Rob admitted in the thread this is in general allowed
> > > > configuration, to me it is still confusing - the left-most compatible is
> > > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > > not support it?
> > > >
> > > It looks like dtschema does not support it.
> >
> > The issue is the same as licensed IP where we have a generic
> > compatible and per licensee compatibles in separate schemas. The
> > solution anytime a compatible exists in more than 1 schema is a custom
> > 'select' which excludes that compatible. That would be messy here
> > though due to the large number of compatibles. Perhaps we could
> > instead merge a custom select with the default generated one. Then the
> > schema would just need:
> >
> > select:
> >   not:
> >     properties:
> >       contains:
> >         const: renesas,smarc-evk
> >
> > We'd have to figure out when to merge or not merge. Maybe only merge a
> > 'not' schema.
> >
> Agreed with this approach the select list might keep growing.
>
> >
> > The other way to solve this is simply not having 2 schema files. Why
> > do we have SoC/board schemas under a CPU arch directory? There's
> > nothing architecture specific about them (I have the same opinion on
> > .dts files too). So I'd be in favor of putting all root node schemas
> > in one directory.
> >
> Agreed, but what do we name the directory which has root node schemas?

'root' for root node schemas?

>
> Geert, are you ok with moving the schema out and having a single file
> for all the Renesas SoC'/Boards?

I didn't say I was in favor of putting 1 schema there, but 'all root
node schemas'.


Rob

Re: dtbs_check issue

[Lad, Prabhakar]

On Thu, Jul 21, 2022 at 11:24 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
> >
> > Hi Rob,
> >
> > On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> > > <prabhakar.csengg@gmail.com> wrote:
> > > >
> > > > Hi Krzysztof,
> > > >
> > > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > >
> > > > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > > > dtbs_check failures.
> > > > > >
> > > > > > Any pointers on how I can get around this issue?
> > > > >
> > > > > Few months ago:
> > > > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > > > >
> > > > Thanks for the link.
> > > >
> > > > > Although Rob admitted in the thread this is in general allowed
> > > > > configuration, to me it is still confusing - the left-most compatible is
> > > > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > > > not support it?
> > > > >
> > > > It looks like dtschema does not support it.
> > >
> > > The issue is the same as licensed IP where we have a generic
> > > compatible and per licensee compatibles in separate schemas. The
> > > solution anytime a compatible exists in more than 1 schema is a custom
> > > 'select' which excludes that compatible. That would be messy here
> > > though due to the large number of compatibles. Perhaps we could
> > > instead merge a custom select with the default generated one. Then the
> > > schema would just need:
> > >
> > > select:
> > >   not:
> > >     properties:
> > >       contains:
> > >         const: renesas,smarc-evk
> > >
> > > We'd have to figure out when to merge or not merge. Maybe only merge a
> > > 'not' schema.
> > >
> > Agreed with this approach the select list might keep growing.
> >
> > >
> > > The other way to solve this is simply not having 2 schema files. Why
> > > do we have SoC/board schemas under a CPU arch directory? There's
> > > nothing architecture specific about them (I have the same opinion on
> > > .dts files too). So I'd be in favor of putting all root node schemas
> > > in one directory.
> > >
> > Agreed, but what do we name the directory which has root node schemas?
>
> 'root' for root node schemas?
>
> >
> > Geert, are you ok with moving the schema out and having a single file
> > for all the Renesas SoC'/Boards?
>
> I didn't say I was in favor of putting 1 schema there, but 'all root
> node schemas'.
>
Thanks for the clarification.

Cheers,
Prabhakar

Re: dtbs_check issue

[Lad, Prabhakar]

On Fri, Jul 22, 2022 at 12:08 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> On Thu, Jul 21, 2022 at 11:24 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar
> > <prabhakar.csengg@gmail.com> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > >
> > > > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> > > > <prabhakar.csengg@gmail.com> wrote:
> > > > >
> > > > > Hi Krzysztof,
> > > > >
> > > > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > > >
> > > > > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > > > > dtbs_check failures.
> > > > > > >
> > > > > > > Any pointers on how I can get around this issue?
> > > > > >
> > > > > > Few months ago:
> > > > > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > > > > >
> > > > > Thanks for the link.
> > > > >
> > > > > > Although Rob admitted in the thread this is in general allowed
> > > > > > configuration, to me it is still confusing - the left-most compatible is
> > > > > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > > > > not support it?
> > > > > >
> > > > > It looks like dtschema does not support it.
> > > >
> > > > The issue is the same as licensed IP where we have a generic
> > > > compatible and per licensee compatibles in separate schemas. The
> > > > solution anytime a compatible exists in more than 1 schema is a custom
> > > > 'select' which excludes that compatible. That would be messy here
> > > > though due to the large number of compatibles. Perhaps we could
> > > > instead merge a custom select with the default generated one. Then the
> > > > schema would just need:
> > > >
> > > > select:
> > > >   not:
> > > >     properties:
> > > >       contains:
> > > >         const: renesas,smarc-evk
> > > >
Being a novice here with the select, I added the below to ignore the
arm schema if its the RISC-V board:

diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml
b/Documentation/devicetree/bindings/arm/renesas.yaml
index ff80152f092f..77e78136bfce 100644
--- a/Documentation/devicetree/bindings/arm/renesas.yaml
+++ b/Documentation/devicetree/bindings/arm/renesas.yaml
@@ -9,6 +9,16 @@ title: Renesas SH-Mobile, R-Mobile, and R-Car
Platform Device Tree Bindings
 maintainers:
   - Geert Uytterhoeven <geert+renesas@glider.be>

+# We want ignore this schema if the board is of RISC-V arch
+select:
+  not:
+    properties:
+      compatible:
+        contains:
+          const: renesas,r9a07g043f1
+    required:
+      - compatible
+
 properties:
   $nodename:
     const: '/'

But when I run the dt_binding_check, I get the below issues:

prasmi@prasmi:~/work/linux$ make ARCH=riscv
CROSS_COMPILE=riscv64-linux-gnu- dt_binding_check
  DTEX    Documentation/devicetree/bindings/arm/renesas.example.dts
  LINT    Documentation/devicetree/bindings
  CHKDT   Documentation/devicetree/bindings/processed-schema.json
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
  DTC     Documentation/devicetree/bindings/arm/renesas.example.dtb
  CHECK   Documentation/devicetree/bindings/arm/renesas.example.dtb
/home/prasmi/work/linux/Documentation/devicetree/bindings/arm/renesas.example.dtb:
/: compatible: 'oneOf' conditional failed, one must be fixed:
    ['foo'] is too short
    /home/prasmi/work/linux/Documentation/devicetree/bindings/arm/renesas.example.dtb:
/: compatible: 'oneOf' conditional failed, one must be fixed:
        ['foo'] is too short
        'shimafuji,kingfisher' was expected
    'foo' is not one of ['renesas,kzm9d']
    'foo' is not one of ['renesas,genmai', 'renesas,gr-peach',
'renesas,rskrza1']
    'foo' is not one of ['renesas,rza2mevb']
    'foo' is not one of ['renesas,kzm9g']
    'foo' is not one of ['renesas,ape6evm']
    'foo' is not one of ['renesas,armadillo800eva']
    'foo' is not one of ['iwave,g21m']
    'foo' is not one of ['iwave,g21d']
    'foo' is not one of ['iwave,g20d']
    'foo' is not one of ['iwave,g20m', 'renesas,sk-rzg1m']
    'foo' is not one of ['iwave,g20m']
    'foo' is not one of ['iwave,g22m', 'renesas,sk-rzg1e']
    'iwave,g22d' was expected
    'foo' is not one of ['iwave,g23s']
    'foo' is not one of ['hoperun,hihope-rzg2m', 'beacon,beacon-rzg2m']
    'foo' is not one of ['hoperun,hihope-rzg2-ex']
    'foo' is not one of ['beacon,beacon-rzg2n', 'hoperun,hihope-rzg2n']
    'foo' is not one of ['si-linux,cat874']
    'foo' is not one of ['si-linux,cat875']
    'foo' is not one of ['beacon,beacon-rzg2h', 'hoperun,hihope-rzg2h']
    'foo' is not one of ['renesas,bockw']
    'foo' is not one of ['renesas,marzen']
    'foo' is not one of ['renesas,lager', 'renesas,stout']
    'foo' is not one of ['renesas,henninger', 'renesas,koelsch',
'renesas,porter']
    'foo' is not one of ['renesas,blanche', 'renesas,wheat']
    'foo' is not one of ['renesas,gose']
    'foo' is not one of ['renesas,alt', 'renesas,silk']
    'foo' is not one of ['renesas,h3ulcb', 'renesas,salvator-x',
'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3ulcb', 'renesas,salvator-x',
'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3ulcb', 'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3nulcb', 'renesas,salvator-x',
'renesas,salvator-xs']
    'foo' is not one of ['renesas,eagle', 'renesas,v3msk']
    'foo' is not one of ['renesas,condor', 'renesas,v3hsk']
    'foo' is not one of ['renesas,ebisu']
    'foo' is not one of ['renesas,draak']
    'foo' is not one of ['renesas,falcon-cpu']
    'foo' is not one of ['renesas,falcon-breakout']
    'foo' is not one of ['renesas,spider-cpu']
    'foo' is not one of ['renesas,spider-breakout']
    'foo' is not one of ['renesas,white-hawk-cpu']
    'foo' is not one of ['renesas,white-hawk-breakout']
    'foo' is not one of ['renesas,h3ulcb', 'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3nulcb', 'renesas,salvator-xs']
    'foo' is not one of ['renesas,rzn1d400-db']
    'foo' is not one of ['renesas,smarc-evk']
    'foo' is not one of ['renesas,rzv2mevk2']
    From schema:
/home/prasmi/work/linux/Documentation/devicetree/bindings/arm/renesas.yaml
  DTC     Documentation/devicetree/bindings/riscv/renesas.example.dtb
  CHECK   Documentation/devicetree/bindings/riscv/renesas.example.dtb
/home/prasmi/work/linux/Documentation/devicetree/bindings/riscv/renesas.example.dtb:
/: compatible: 'oneOf' conditional failed, one must be fixed:
    ['foo'] is too short
    /home/prasmi/work/linux/Documentation/devicetree/bindings/riscv/renesas.example.dtb:
/: compatible: 'oneOf' conditional failed, one must be fixed:
        ['foo'] is too short
        'shimafuji,kingfisher' was expected
    'foo' is not one of ['renesas,kzm9d']
    'foo' is not one of ['renesas,genmai', 'renesas,gr-peach',
'renesas,rskrza1']
    'foo' is not one of ['renesas,rza2mevb']
    'foo' is not one of ['renesas,kzm9g']
    'foo' is not one of ['renesas,ape6evm']
    'foo' is not one of ['renesas,armadillo800eva']
    'foo' is not one of ['iwave,g21m']
    'foo' is not one of ['iwave,g21d']
    'foo' is not one of ['iwave,g20d']
    'foo' is not one of ['iwave,g20m', 'renesas,sk-rzg1m']
    'foo' is not one of ['iwave,g20m']
    'foo' is not one of ['iwave,g22m', 'renesas,sk-rzg1e']
    'iwave,g22d' was expected
    'foo' is not one of ['iwave,g23s']
    'foo' is not one of ['hoperun,hihope-rzg2m', 'beacon,beacon-rzg2m']
    'foo' is not one of ['hoperun,hihope-rzg2-ex']
    'foo' is not one of ['beacon,beacon-rzg2n', 'hoperun,hihope-rzg2n']
    'foo' is not one of ['si-linux,cat874']
    'foo' is not one of ['si-linux,cat875']
    'foo' is not one of ['beacon,beacon-rzg2h', 'hoperun,hihope-rzg2h']
    'foo' is not one of ['renesas,bockw']
    'foo' is not one of ['renesas,marzen']
    'foo' is not one of ['renesas,lager', 'renesas,stout']
    'foo' is not one of ['renesas,henninger', 'renesas,koelsch',
'renesas,porter']
    'foo' is not one of ['renesas,blanche', 'renesas,wheat']
    'foo' is not one of ['renesas,gose']
    'foo' is not one of ['renesas,alt', 'renesas,silk']
    'foo' is not one of ['renesas,h3ulcb', 'renesas,salvator-x',
'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3ulcb', 'renesas,salvator-x',
'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3ulcb', 'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3nulcb', 'renesas,salvator-x',
'renesas,salvator-xs']
    'foo' is not one of ['renesas,eagle', 'renesas,v3msk']
    'foo' is not one of ['renesas,condor', 'renesas,v3hsk']
    'foo' is not one of ['renesas,ebisu']
    'foo' is not one of ['renesas,draak']
    'foo' is not one of ['renesas,falcon-cpu']
    'foo' is not one of ['renesas,falcon-breakout']
    'foo' is not one of ['renesas,spider-cpu']
    'foo' is not one of ['renesas,spider-breakout']
    'foo' is not one of ['renesas,white-hawk-cpu']
    'foo' is not one of ['renesas,white-hawk-breakout']
    'foo' is not one of ['renesas,h3ulcb', 'renesas,salvator-xs']
    'foo' is not one of ['renesas,m3nulcb', 'renesas,salvator-xs']
    'foo' is not one of ['renesas,rzn1d400-db']
    'foo' is not one of ['renesas,smarc-evk']
    'foo' is not one of ['renesas,rzv2mevk2']
    From schema:
/home/prasmi/work/linux/Documentation/devicetree/bindings/arm/renesas.yaml

Any pointers on what I'm missing.

Cheers,
Prabhakar

Re: dtbs_check issue

[Rob Herring]

On Fri, Jul 22, 2022 at 7:29 AM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> On Fri, Jul 22, 2022 at 12:08 PM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
> >
> > On Thu, Jul 21, 2022 at 11:24 PM Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar
> > > <prabhakar.csengg@gmail.com> wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > > >
> > > > > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> > > > > <prabhakar.csengg@gmail.com> wrote:
> > > > > >
> > > > > > Hi Krzysztof,
> > > > > >
> > > > > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > > > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > > > >
> > > > > > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > > > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > > > > > dtbs_check failures.
> > > > > > > >
> > > > > > > > Any pointers on how I can get around this issue?
> > > > > > >
> > > > > > > Few months ago:
> > > > > > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > > > > > >
> > > > > > Thanks for the link.
> > > > > >
> > > > > > > Although Rob admitted in the thread this is in general allowed
> > > > > > > configuration, to me it is still confusing - the left-most compatible is
> > > > > > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > > > > > not support it?
> > > > > > >
> > > > > > It looks like dtschema does not support it.
> > > > >
> > > > > The issue is the same as licensed IP where we have a generic
> > > > > compatible and per licensee compatibles in separate schemas. The
> > > > > solution anytime a compatible exists in more than 1 schema is a custom
> > > > > 'select' which excludes that compatible. That would be messy here
> > > > > though due to the large number of compatibles. Perhaps we could
> > > > > instead merge a custom select with the default generated one. Then the
> > > > > schema would just need:
> > > > >
> > > > > select:
> > > > >   not:
> > > > >     properties:
> > > > >       contains:
> > > > >         const: renesas,smarc-evk
> > > > >
> Being a novice here with the select, I added the below to ignore the
> arm schema if its the RISC-V board:
>
> diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml
> b/Documentation/devicetree/bindings/arm/renesas.yaml
> index ff80152f092f..77e78136bfce 100644
> --- a/Documentation/devicetree/bindings/arm/renesas.yaml
> +++ b/Documentation/devicetree/bindings/arm/renesas.yaml
> @@ -9,6 +9,16 @@ title: Renesas SH-Mobile, R-Mobile, and R-Car
> Platform Device Tree Bindings
>  maintainers:
>    - Geert Uytterhoeven <geert+renesas@glider.be>
>
> +# We want ignore this schema if the board is of RISC-V arch
> +select:
> +  not:
> +    properties:
> +      compatible:
> +        contains:
> +          const: renesas,r9a07g043f1
> +    required:
> +      - compatible
> +
>  properties:
>    $nodename:
>      const: '/'
>
> But when I run the dt_binding_check, I get the below issues:

That would only work if we change how 'select' is generated. As I
said, the above would have to be merged with what we normally generate
(see processed-schema.json for what that looks like).

Rob

Re: dtbs_check issue

[Lad, Prabhakar]

Hi Rob,

On Fri, Jul 22, 2022 at 5:39 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Fri, Jul 22, 2022 at 7:29 AM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
> >
> > On Fri, Jul 22, 2022 at 12:08 PM Lad, Prabhakar
> > <prabhakar.csengg@gmail.com> wrote:
> > >
> > > On Thu, Jul 21, 2022 at 11:24 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > >
> > > > On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar
> > > > <prabhakar.csengg@gmail.com> wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > > > >
> > > > > > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> > > > > > <prabhakar.csengg@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Krzysztof,
> > > > > > >
> > > > > > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > > > > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > > > > >
> > > > > > > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > > > > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > > > > > > dtbs_check failures.
> > > > > > > > >
> > > > > > > > > Any pointers on how I can get around this issue?
> > > > > > > >
> > > > > > > > Few months ago:
> > > > > > > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > > > > > > >
> > > > > > > Thanks for the link.
> > > > > > >
> > > > > > > > Although Rob admitted in the thread this is in general allowed
> > > > > > > > configuration, to me it is still confusing - the left-most compatible is
> > > > > > > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > > > > > > not support it?
> > > > > > > >
> > > > > > > It looks like dtschema does not support it.
> > > > > >
> > > > > > The issue is the same as licensed IP where we have a generic
> > > > > > compatible and per licensee compatibles in separate schemas. The
> > > > > > solution anytime a compatible exists in more than 1 schema is a custom
> > > > > > 'select' which excludes that compatible. That would be messy here
> > > > > > though due to the large number of compatibles. Perhaps we could
> > > > > > instead merge a custom select with the default generated one. Then the
> > > > > > schema would just need:
> > > > > >
> > > > > > select:
> > > > > >   not:
> > > > > >     properties:
> > > > > >       contains:
> > > > > >         const: renesas,smarc-evk
> > > > > >
> > Being a novice here with the select, I added the below to ignore the
> > arm schema if its the RISC-V board:
> >
> > diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml
> > b/Documentation/devicetree/bindings/arm/renesas.yaml
> > index ff80152f092f..77e78136bfce 100644
> > --- a/Documentation/devicetree/bindings/arm/renesas.yaml
> > +++ b/Documentation/devicetree/bindings/arm/renesas.yaml
> > @@ -9,6 +9,16 @@ title: Renesas SH-Mobile, R-Mobile, and R-Car
> > Platform Device Tree Bindings
> >  maintainers:
> >    - Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > +# We want ignore this schema if the board is of RISC-V arch
> > +select:
> > +  not:
> > +    properties:
> > +      compatible:
> > +        contains:
> > +          const: renesas,r9a07g043f1
> > +    required:
> > +      - compatible
> > +
> >  properties:
> >    $nodename:
> >      const: '/'
> >
> > But when I run the dt_binding_check, I get the below issues:
>
> That would only work if we change how 'select' is generated. As I
> said, the above would have to be merged with what we normally generate
> (see processed-schema.json for what that looks like).
>
I'm a bit lost here!

Could you please elaborate what you mean by merging a custom select
with the default generated one. When I compared the
processed-schema.json with/without my changes they were the same.

Cheers,
Prabhakar

Re: dtbs_check issue

[Rob Herring]

On Mon, Jul 25, 2022 at 4:02 AM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> Hi Rob,
>
> On Fri, Jul 22, 2022 at 5:39 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Fri, Jul 22, 2022 at 7:29 AM Lad, Prabhakar
> > <prabhakar.csengg@gmail.com> wrote:
> > >
> > > On Fri, Jul 22, 2022 at 12:08 PM Lad, Prabhakar
> > > <prabhakar.csengg@gmail.com> wrote:
> > > >
> > > > On Thu, Jul 21, 2022 at 11:24 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > > >
> > > > > On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar
> > > > > <prabhakar.csengg@gmail.com> wrote:
> > > > > >
> > > > > > Hi Rob,
> > > > > >
> > > > > > On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > > > > >
> > > > > > > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> > > > > > > <prabhakar.csengg@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Krzysztof,
> > > > > > > >
> > > > > > > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > > > > > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > > > > > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > > > > > > > dtbs_check failures.
> > > > > > > > > >
> > > > > > > > > > Any pointers on how I can get around this issue?
> > > > > > > > >
> > > > > > > > > Few months ago:
> > > > > > > > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > > > > > > > >
> > > > > > > > Thanks for the link.
> > > > > > > >
> > > > > > > > > Although Rob admitted in the thread this is in general allowed
> > > > > > > > > configuration, to me it is still confusing - the left-most compatible is
> > > > > > > > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > > > > > > > not support it?
> > > > > > > > >
> > > > > > > > It looks like dtschema does not support it.
> > > > > > >
> > > > > > > The issue is the same as licensed IP where we have a generic
> > > > > > > compatible and per licensee compatibles in separate schemas. The
> > > > > > > solution anytime a compatible exists in more than 1 schema is a custom
> > > > > > > 'select' which excludes that compatible. That would be messy here
> > > > > > > though due to the large number of compatibles. Perhaps we could
> > > > > > > instead merge a custom select with the default generated one. Then the
> > > > > > > schema would just need:
> > > > > > >
> > > > > > > select:
> > > > > > >   not:
> > > > > > >     properties:
> > > > > > >       contains:
> > > > > > >         const: renesas,smarc-evk
> > > > > > >
> > > Being a novice here with the select, I added the below to ignore the
> > > arm schema if its the RISC-V board:
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml
> > > b/Documentation/devicetree/bindings/arm/renesas.yaml
> > > index ff80152f092f..77e78136bfce 100644
> > > --- a/Documentation/devicetree/bindings/arm/renesas.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/renesas.yaml
> > > @@ -9,6 +9,16 @@ title: Renesas SH-Mobile, R-Mobile, and R-Car
> > > Platform Device Tree Bindings
> > >  maintainers:
> > >    - Geert Uytterhoeven <geert+renesas@glider.be>
> > >
> > > +# We want ignore this schema if the board is of RISC-V arch
> > > +select:
> > > +  not:
> > > +    properties:
> > > +      compatible:
> > > +        contains:
> > > +          const: renesas,r9a07g043f1
> > > +    required:
> > > +      - compatible
> > > +
> > >  properties:
> > >    $nodename:
> > >      const: '/'
> > >
> > > But when I run the dt_binding_check, I get the below issues:
> >
> > That would only work if we change how 'select' is generated. As I
> > said, the above would have to be merged with what we normally generate
> > (see processed-schema.json for what that looks like).
> >
> I'm a bit lost here!
>
> Could you please elaborate what you mean by merging a custom select
> with the default generated one. When I compared the
> processed-schema.json with/without my changes they were the same.

dtschema generates 'select' if it is not present and $nodename or
compatible properties are. It would instead need to combine your
'select' above with what it generates instead. Otherwise, wiht just
the above, it is going to match every node with compatible not
containing 'renesas,r9a07g043f1' which would be 99.9% of nodes.

Rob

Re: dtbs_check issue

[Lad, Prabhakar]

Hi Rob,

On Mon, Jul 25, 2022 at 6:40 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Jul 25, 2022 at 4:02 AM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
> >
> > Hi Rob,
> >
> > On Fri, Jul 22, 2022 at 5:39 PM Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > On Fri, Jul 22, 2022 at 7:29 AM Lad, Prabhakar
> > > <prabhakar.csengg@gmail.com> wrote:
> > > >
> > > > On Fri, Jul 22, 2022 at 12:08 PM Lad, Prabhakar
> > > > <prabhakar.csengg@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jul 21, 2022 at 11:24 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > > > >
> > > > > > On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar
> > > > > > <prabhakar.csengg@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar
> > > > > > > > <prabhakar.csengg@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Krzysztof,
> > > > > > > > >
> > > > > > > > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski
> > > > > > > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On 21/07/2022 17:07, Lad, Prabhakar wrote:
> > > > > > > > > > > Fyi keeping even a single SMARC board in arm renesas.yaml schema I see
> > > > > > > > > > > dtbs_check failures.
> > > > > > > > > > >
> > > > > > > > > > > Any pointers on how I can get around this issue?
> > > > > > > > > >
> > > > > > > > > > Few months ago:
> > > > > > > > > > https://lore.kernel.org/linux-devicetree/cf7728fd-b5c8-cd3d-6074-d27f38f86545@linaro.org/
> > > > > > > > > >
> > > > > > > > > Thanks for the link.
> > > > > > > > >
> > > > > > > > > > Although Rob admitted in the thread this is in general allowed
> > > > > > > > > > configuration, to me it is still confusing - the left-most compatible is
> > > > > > > > > > not the most specific. Non obvious, confusing and it seems dtschema does
> > > > > > > > > > not support it?
> > > > > > > > > >
> > > > > > > > > It looks like dtschema does not support it.
> > > > > > > >
> > > > > > > > The issue is the same as licensed IP where we have a generic
> > > > > > > > compatible and per licensee compatibles in separate schemas. The
> > > > > > > > solution anytime a compatible exists in more than 1 schema is a custom
> > > > > > > > 'select' which excludes that compatible. That would be messy here
> > > > > > > > though due to the large number of compatibles. Perhaps we could
> > > > > > > > instead merge a custom select with the default generated one. Then the
> > > > > > > > schema would just need:
> > > > > > > >
> > > > > > > > select:
> > > > > > > >   not:
> > > > > > > >     properties:
> > > > > > > >       contains:
> > > > > > > >         const: renesas,smarc-evk
> > > > > > > >
> > > > Being a novice here with the select, I added the below to ignore the
> > > > arm schema if its the RISC-V board:
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml
> > > > b/Documentation/devicetree/bindings/arm/renesas.yaml
> > > > index ff80152f092f..77e78136bfce 100644
> > > > --- a/Documentation/devicetree/bindings/arm/renesas.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/renesas.yaml
> > > > @@ -9,6 +9,16 @@ title: Renesas SH-Mobile, R-Mobile, and R-Car
> > > > Platform Device Tree Bindings
> > > >  maintainers:
> > > >    - Geert Uytterhoeven <geert+renesas@glider.be>
> > > >
> > > > +# We want ignore this schema if the board is of RISC-V arch
> > > > +select:
> > > > +  not:
> > > > +    properties:
> > > > +      compatible:
> > > > +        contains:
> > > > +          const: renesas,r9a07g043f1
> > > > +    required:
> > > > +      - compatible
> > > > +
> > > >  properties:
> > > >    $nodename:
> > > >      const: '/'
> > > >
> > > > But when I run the dt_binding_check, I get the below issues:
> > >
> > > That would only work if we change how 'select' is generated. As I
> > > said, the above would have to be merged with what we normally generate
> > > (see processed-schema.json for what that looks like).
> > >
> > I'm a bit lost here!
> >
> > Could you please elaborate what you mean by merging a custom select
> > with the default generated one. When I compared the
> > processed-schema.json with/without my changes they were the same.
>
> dtschema generates 'select' if it is not present and $nodename or
> compatible properties are. It would instead need to combine your
> 'select' above with what it generates instead. Otherwise, wiht just
> the above, it is going to match every node with compatible not
> containing 'renesas,r9a07g043f1' which would be 99.9% of nodes.
>
Thanks for the pointer, I managed to get the select working with ARM
and RISC-V schema.

CHeers,
Prabhakar