Hi Rob, On 14:37 Fri 30 Aug , Rob Herring wrote: > On Thu, Aug 29, 2024 at 11:26 AM Andrea della Porta > <andrea.porta@xxxxxxxx> wrote: > > > > Hi Rob, > > ... > > I think simple-bus where you have it is fine. It is really 1 level up > that needs to be specified. Basically something that's referenced from > the specific PCI device's schema (e.g. the RP1 schema (which you are > missing)). > > That schema needs to roughly look like this: > > properties: > "#address-cells": > const: 3 > "#size-cells": > const: 2 > ranges: > minItems: 1 > maxItems: 6 > items: > additionalItems: true > items: > - maximum: 5 # The BAR number > - const: 0 > - const: 0 > - # TODO: valid PCI memory flags > > patternProperties: > "^bar-bus@[0-5]$": > type: object > additionalProperties: true > properties: > compatible: > const: simple-bus > ranges: true > Hmmm.. not sure how this is going to work. The PCI device (RP1) will havei, at runtime, a compatible like this: compatible = "pci1de4,1\0pciclass,0200000\0pciclass,0200"; that is basically generated automatically by the OF framework. So, in the schema you proposed above, I can put something like: properties: compatible: contains: pattern: '^pci1de4,1' or maybe I could omit the compatible entirely, like in: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-iommu.yaml that seems to refer to generic compatible values. In both cases though, I don't see how these binding could work with make dt_binding_check, since there's no compatible known at compile time (for the first approach), or no compatible at all (the second approach). Is it intended only as a loose documentation? Or are you proposing that for a future new bus (hence with a new, specific, compatible) that could be described by the schema above? Many thanks, Andrea > There were some discussions around interrupt handling that might also > factor into this. > > Rob