On 15/10/2024 13:28, Laurent Pinchart wrote: > Hi Krzysztof, > > On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote: >> On 14/10/2024 22:29, Laurent Pinchart wrote: >>> On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote: >>>> On 14/10/2024 10:31, Bryan O'Donoghue wrote: >>>>> On 14/10/2024 08:45, Krzysztof Kozlowski wrote: >>>>>> I do not understand the reasoning behind this change at all. I don't >>>>>> think DT maintainers ever suggested it (in fact, rather opposite: >>>>>> suggested using unevaluatedProps) and I think is not a consensus of any >>>>>> talks. >>>>> >>>>> No there is not but then, how do you give consistent feedback except >>>>> proposing something to be a baseline. >>>>> >>>>> On the one hand you have upstream additionalProperties: false and >>>>> unevaluatedProperites: false - it'd be better to have a consistent >>>>> message on which is to be used. >>>> >>>> Well, I am afraid that push towards additionalProps will lead to grow >>>> common schema (video-interface-devices or video-interfaces) into huge >>>> one-fit-all binding. And that's not good. >>>> >>>> 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. >>> >>> I think splitting large schemas per class is a good idea, but the >>> problem will still exist. For instance, if we were to move the >>> CSI-2-specific properties to a separate schema, that schema would define >>> clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and >>> clock-noncontinuous properties do not apply to every device, how would >>> we then handle that ? I see three options: >> >> Why is this a problem? Why is this a problem here, but not in other >> subsystems having exactly the same case? > > I won't talk for other subsystems, but I can say I see value in > explicitly expressing what properties are valid for a device in DT > bindings both to inform DT authors and to perform validation on DT > sources. That's the whole point of YAML schemas, and I can't see a good > reason not to use the tooling we have developed when it has an easy way > to do the job. I understand. The benefit, which you see, comes with complexity of the binding and need of listing properties. We do not enforce such rules (narrowing common schema in very strict way) in other subsystems, maybe with exception of input and touchscreen devices, but there common schema is quite big. And DT maintainers suggested to drop such code even for these, BTW. Best regards, Krzysztof
