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