[PATCH v2 3/8] dt-bindings: marvell: a38x: add solidrun armada 388 clearfog boards

[Krzysztof Kozlowski]

On 24/12/2023 17:29, Josua Mayer wrote:

>>>>> +      - description: |
>>>>> +          SolidRun Armada 388 SoM based clearfog board. This is
>>>>> +          equivalent to clearfog pro, but lacks the "pro" label
>>>>> +          in dtb filename and compatible strings.
>>>>> +        items:
>>>>> +          - const: solidrun,clearfog-a1
>>>> SoM cannot be alone.
>>> Please confirm, I think my wording above was not clear.
>>>
>>> I meant to say "clearfog" devices based on a SoM,.
>>> Armada 388 Clearfog Base / Pro are combinations of SoM and carrier.
>>> Current device-trees do not mention a som-specific compatible string though.
>> So Clearfog Base is a board, then what is Clearfog A1?
> "Clearfog A1" is printed on the silk screen of a Clearfog Pro revision 
> 2.0 or earlier.
> I don't have a later revision to look at.
> So Clearfog A1 and Clearfog Pro  and Clearfog Pro A1 all mean the same 
> board,
> Clearfog Base (+-A1) mean the other board.

Then if A1 and Pro A1 are the same, why do you have A1 here and Pro A1
second time in the entry below?

> 
> "-a1" of the compatible string is already used by openwrt to differentiate.

Does not matter, we do not document out of tree users.

> 
>>
>>> This is in contrast to "Clearfog GTR" which
>>> a) uses aramda-385
>>> b) solders SoC to the board.
>>>
>>>>> +          - const: marvell,armada388
>>>>> +          - const: marvell,armada385
>>>>> +          - const: marvell,armada380
>>>>> +
>>>>> +      - description: SolidRun Armada 388 SoM based clearfog board variants
>>>>> +        items:
>>>>> +          - enum:
>>>>> +             - solidrun,clearfog-base-a1
>>>> Board has name "base"?
>>> Yes.
>>> In marketing and in device-tree model field the board names are
>>> Clearfog Base, Clearfog Pro
>> Then clearfog-base or clearfog-a1-base, but why a1 is at the end? Or is
>> it the case that Clearfog Base can have different SoMs? Think what you
>> have there and choose appropriate compatibles. See Renesas SMARC for one
>> choice and iMX Toradex boards for different example
> Conceptually at this point, is it worth changing the compatibles of 
> existing boards to make sense?

There are no existing boards - you add them here. I have doubts whether
you described it properly, thus my questions.


> Or better to describe them in yaml as they are now (ensuring language is 
> understood)?
> 
> If I try really hard, I can add a new armada-388 som compatible, but 
> that opens another can.
> There are other boards also based on the solidrun armada-388 SoMs, e.g. 
> helios4 - and
> there is no shared -som dtsi.
> Effectively I guess they are all just individual boards, maybe not worth 
> mentioning "SoM".
> 

Depends, is this SoM? If yes, usually you should have SoM DTSI and SoM
compatible.

Best regards,
Krzysztof