[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68fd00b8-d6f1-463b-9d0d-b77bf9364f7f@linaro.org>
Date: Thu, 28 Mar 2024 10:41:50 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Josua Mayer <josua@...id-run.com>, Andrew Lunn <andrew@...n.ch>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: Yazan Shhady <yazan.shhady@...id-run.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130
clearfog boards
On 28/03/2024 10:33, Josua Mayer wrote:
>>
>>> 2. 88F8215, SouthBridge Communication Processor, System on Chip
>>> (only usable in combination with a CN9130)
>>>
>>> Now, in terms of compatible string, what happens when a board
>>> has multiples of these?
>> Multiple of CN9130? 2x CN9130?
> this specifically is an academic question,
> the main point is multiple southbridges to one CN9130.
I did not know to what you refer.
>>
>> You <cut> should know what is this about and come
>> with explanation to the community.
> If I was to come up with something new, without looking at existing
> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> I would describe the hardware like this:
>
> SolidRun "CN9131" SolidWAN board is comptible with:
> - solidrun,cn9131-solidwan:
> name of the carrier board, and name of the complete product
> includes one southbridge chip, but I don't need to mention it?
> - solidrun,cn9130-sr-som:
> just the som, including 1x CN9130 SoC
> - marvell,cn9130:
> this is the SoC, internally combining AP+CP
> AP *could* be mentioned, but I don't see a reason
With an explanation in commit msg about not using other compatible
fallbacks, this looks good to me.
>
>> You<cut>r platform maintainers should know what is this about and come
>> with explanation to the community.
> Is there a way forward?
> Would it be worth challenging the existing bindings by proposing (RFC)
> specific changes in line with what I described above?
It all depends on "what" and "why" you want to do. I don't know.
Best regards,
Krzysztof
Powered by blists - more mailing lists