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? Yours, Linus Walleij