linux-kernel - Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ea0feb4-4d7e-4a10-9254-b034e368e8ad@solid-run.com>
Date: Thu, 28 Mar 2024 09:33:23 +0000
From: Josua Mayer <josua@...id-run.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, 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

Hi Krzysztof,
Thank you for all the comments so far!

Am 28.03.24 um 10:14 schrieb Krzysztof Kozlowski:
> On 27/03/2024 11:55, Josua Mayer wrote:
>
>>> I don't even understand what is your case.
>> I see :(
>> Yes there is a disconnect *somewhere*.
>>
> Your way of quoting, including removing blank lines, weird wrapping,
> does not make it easy to answer anything here. Use decent email client
> which solves all these problems.
>
>> I shall try again:
>> Marvell is selling two chips:
>> 1. CN9130, High-Performance Multi-Core CPU, System on Chip
>> (can be used alone)
> So this is the main SoC?
Correct.
>
>> 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.
> Nothing happens, does not really matter.
> Anyway the compatible is just to uniquely identify the device for users,
> not represent some programming model, because there is no programming
> model of a board.
>
>>> What is 9131 and 9132?
>> I have no idea who came up with 9131 and 9132.
>> But explanation is given by Grzegorz Jaszczyk <jaz@...ihalf.com>
>> when he submitted cn9131-db.dts (Marvell evaluation board):
>>
>> Extend the support of the CN9130 by adding an external CP115.
>> The last number indicates how many external CP115 are used.
> You use the compatibles in your patchset, so you should know, not me.I
> have zero knowledge, also actually almost zero interest, in learning
> your particular platform.

Fair enough.

> I tried to fixup some bindings and maintainers
> for Marvell: failed with not really helpful comments. Therefore I don't
> care anymore about Marvell.
>
> 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

> 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?


sincerely
Josua Mayer