arm/rockchip.yaml - many separate entries instead of enums

Hi Heiko,

I found that Documentation/devicetree/bindings/arm/rockchip.yaml uses pattern of one board per item in oneOf.

This leads to quite big file, with many entries, although gives nice description for each board.

I find enum-based pattern, like FSL [1], much more readable and compact. What do you think? I could re-organize the arm/rockchip.yaml, but I don't want to mess with your preference.

[1]
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/arm/fsl.yaml#L191

Best regards,
Krzysztof

Hey :-) ,

Am Dienstag, 29. März 2022, 19:05:24 CEST schrieb Krzysztof Kozlowski:

Quoted 7 lines

Hi Heiko,

I found that Documentation/devicetree/bindings/arm/rockchip.yaml uses pattern of one board per item in oneOf.

This leads to quite big file, with many entries, although gives nice description for each board.

that was the original intention in doing it this way, preserving the normal readability while adding machine readability to it :-)

Quoted 3 lines

I find enum-based pattern, like FSL [1], much more readable and compact. What do you think? I could re-organize the arm/rockchip.yaml, but I don't want to mess with your preference.

I do like the current way as it does only contains one way of doing it.

As far as I can see, the fsl one has multiple types, like the one you pointed at, for a list of boards + one soc that works for the simple plethora of regular boards.

But also additional types that do it similarly to Rockchip like the
"i.MX6Q Advantech DMS-BA16 boards"
directly below it.

As we have both cases here as well, I really don't like this mix but instead really like to have only one approach, hence the one-entry-per-board-family we do in rockchip.yaml [2]

For human readability I really do consider having _one_ way of describing boards superior to mixing approaches and the automated parsing doesn't care, as long as the syntax is correct ;-)