On 14/10/2024 11:03, Bryan O'Donoghue wrote: > On 14/10/2024 09:47, Krzysztof Kozlowski wrote: >> If a common binding for a group of devices encourages you to list its >> subset, then it is not that common. >> >> Solution is to fix that, e.g. split it per classes of devices. > > It might be possible to have > > $ref: /schemas/media/video-interfaces-endpoint-defaults.yaml# > > which declares the typical list -> > > $ref: /schemas/media/video-interfaces.yaml# > additonalProperties:false I meant something else - define common schema matching this class of devices. Not a schema for some defaults. This is supposed to reflect how we look at hardware, not some library of schemas or library of functions. > > properties: > data-lanes: true > link-frequencies: true > remote-endpoints: true and I still don't like all these. I rather expect people to list the hardware constraints or just drop it. I mentioned it some time ago in the first patch you sent, which I think started this entire discussion. > > required: > data-lanes > link-frequencies > remote-endpoints > > and then if you need say clock-noncontinuous you'd just include > > $ref: /schemas/media/video-interfaces.yaml# > unevaluatedProperties: false > > and then list whatever you need > >> Or don't care and use unevaluatedProps because it makes people's life >> easier and is still correct. If it is not correct, then this should be >> used as an argument. > > I'll wait to see what people think before progressing this patch further. Best regards, Krzysztof
