On Mon, Dec 16, 2024 at 11:42:30AM +0100, Krzysztof Kozlowski wrote:
> On 16/12/2024 09:32, Laurent Pinchart wrote:
> > On Mon, Dec 16, 2024 at 08:58:49AM +0100, Krzysztof Kozlowski wrote:
> >> On Fri, Dec 13, 2024 at 04:02:59PM +0200, Tomi Valkeinen wrote:
> >>> From: Tomi Valkeinen <tomi.valkeinen+renesas@xxxxxxxxxxxxxxxx>
> >>>
> >>> The binding is missing maxItems for all renesas,cmms and renesas,vsps
> >>> properties. As the amount of cmms or vsps is always a fixed amount, set
> >>> the maxItems to match the minItems.
> >>>
> >>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@xxxxxxxxxxxxxxxx>
> >>> ---
> >>> Documentation/devicetree/bindings/display/renesas,du.yaml | 10 ++++++++++
> >>> 1 file changed, 10 insertions(+)
> >>
> >> The top level property should define widest constraints as well.
> >
> > I'm curious, why is that ? I understand why a top-level default would
> > make sense when it's optionally overridden by model-specific values, but
> > in this case there's no such default. Every SoC has its own fixed value.
>
> Because otherwise top level property does not have proper description
> and we expect properties to be defined at top-level.
Is it invalid YAML schema to have
renesas,cmms:
description: ......
with the min/maxItems in the conditional blocks ? Or did you mean, by
proper description, not just the description field ? We could have
renesas,cmms:
description: ......
minItems: 1
maxItems: 256
but I really don't see what that would bring from a documentation point
of view. Are there tools that depend on minItems and maxItems being
present at the top level ?
--
Regards,
Laurent Pinchart
