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

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

[Krzysztof Kozlowski]

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

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

[Heiko Stübner]

Hey :-) ,

Am Dienstag, 29. März 2022, 19:05:24 CEST schrieb Krzysztof Kozlowski:
> 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 :-)

> 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 ;-)


Heiko

[2] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/arm/rockchip.yaml#L507

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

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

[Krzysztof Kozlowski]

On 29/03/2022 22:54, Heiko Stübner wrote:
> Hey :-) ,
> 
> Am Dienstag, 29. März 2022, 19:05:24 CEST schrieb Krzysztof Kozlowski:
>> 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 :-)
> 
>> 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 ;-)

OK, thanks for clarifying. I won't touch the order then. :)


Best regards,
Krzysztof