On Mon, Jul 19, 2021 at 4:49 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Mon, Jul 19, 2021 at 5:18 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > +patternProperties: > > > + "^.*@[0-7],[0-9a-f]+$": > > > + description: Devices attached to chip selects are represented as > > > + subnodes. > > > + type: object > > > + > > > + properties: > > > + intel,ixp4xx-eb-t1: > > > + description: Address timing, extend address phase with n cycles. > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + maximum: 3 > > (...) > > > > + unevaluatedProperties: false > > > > This will cause failures when implemented. The problem is this won't > > allow any other child node properties as this schema and the device > > schema are evaluated independently. The only way I see to solve this is > > the child node schemas have to include some 'bus properties' schema > > which includes all possible bus controller properties. There's been a > > recent patch set doing this for SPI. At least here, I think the number > > of different child devices on parallel expansion buses are limited. > > > > So spliting this to 2 schema files would be the first step. Minimally, > > just drop unevaluatedProperties. > > SPI upstream simply uses > > additionalProperties: true > > is that acceptable for now? Yes. (That is the default) Rob
