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: - Use "additionalProperties: false" and explicitly list the properties that apply to the device with "$prop: true". This is what this series does. - Use "unevaluatedProperites: false" and explicitly list the properties that do not apply to the device with "$prop: false". The drawback is that any property being added to the common schema will require modifications to all bindings that use the schema. - Use "unevaluatedProperites: false" and don't list any property with "$prop: false". This is what is being done today in many bindings. The drawback is that device tree sources that specify invalid properties for the device will validate. Among those options, my preference goes to the first one. It catches the most issues in device tree sources, while not having the drawback of the second option. It requires explicitly listing the valid properties, but I don't consider that as a drawback, I think it's actually a good thing as it clearly shows to the developers which properties are valid. Are there other options I haven't considered ? > 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. -- Regards, Laurent Pinchart
