Hi Rob, On Fri, Jul 22, 2022 at 5:39 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > On Fri, Jul 22, 2022 at 7:29 AM Lad, Prabhakar > <prabhakar.csengg@xxxxxxxxx> wrote: > > > > On Fri, Jul 22, 2022 at 12:08 PM Lad, Prabhakar > > <prabhakar.csengg@xxxxxxxxx> wrote: > > > > > > On Thu, Jul 21, 2022 at 11:24 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Jul 21, 2022 at 4:18 PM Lad, Prabhakar > > > > <prabhakar.csengg@xxxxxxxxx> wrote: > > > > > > > > > > Hi Rob, > > > > > > > > > > On Thu, Jul 21, 2022 at 5:57 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Thu, Jul 21, 2022 at 9:23 AM Lad, Prabhakar > > > > > > <prabhakar.csengg@xxxxxxxxx> wrote: > > > > > > > > > > > > > > Hi Krzysztof, > > > > > > > > > > > > > > On Thu, Jul 21, 2022 at 4:12 PM Krzysztof Kozlowski > > > > > > > <krzysztof.kozlowski@xxxxxxxxxx> 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@xxxxxxxxxx/ > > > > > > > > > > > > > > > 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@xxxxxxxxx> > > > > +# 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
