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 > > > > > > 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
