linux-kernel - Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles

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]

Date:   Wed, 11 May 2022 23:14:25 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
        "sebastian.hesselbarth@...il.com" <sebastian.hesselbarth@...il.com>,
        "kostap@...vell.com" <kostap@...vell.com>,
        "robert.marko@...tura.hr" <robert.marko@...tura.hr>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X
 compatibles


On 12/05/22 05:02, Andrew Lunn wrote:
> On Wed, May 11, 2022 at 11:10:00AM +1200, Chris Packham wrote:
>> Describe the compatible properties for the Marvell Alleycat5/5X switches
>> with integrated CPUs.
>>
>> Alleycat5:
>> * 98DX2538: 24x1G + 2x10G + 2x10G Stack
>> * 98DX2535: 24x1G + 4x1G Stack
>> * 98DX2532: 8x1G + 2x10G + 2x1G Stack
>> * 98DX2531: 8x1G + 4x1G Stack
>> * 98DX2528: 24x1G + 2x10G + 2x10G Stack
>> * 98DX2525: 24x1G + 4x1G Stack
>> * 98DX2522: 8x1G + 2x10G + 2x1G Stack
>> * 98DX2521: 8x1G + 4x1G Stack
>> * 98DX2518: 24x1G + 2x10G + 2x10G Stack
>> * 98DX2515: 24x1G + 4x1G Stack
>> * 98DX2512: 8x1G + 2x10G + 2x1G Stack
>> * 98DX2511: 8x1G + 4x1G Stack
>>
>> Alleycat5X:
>> * 98DX3500: 24x1G + 6x25G
>> * 98DX3501: 16x1G + 6x10G
>> * 98DX3510: 48x1G + 6x25G
>> * 98DX3520: 24x2.5G + 6x25G
>> * 98DX3530: 48x2.5G + 6x25G
>> * 98DX3540: 12x5G/6x10G + 6x25G
>> * 98DX3550: 24x5G/12x10G + 6x25G
> Hi Chris
>
> When looking at this list, is it just the switch which changes, and
> everything else in the package stays the same?

CPU wise I've been told everything is identical. The differences are all 
in the switch side.

> I'm thinking back to plain Kirkwood. There were 3 Kirkwood SoCs. We
> had kirkwood.dtsi which described everything common to all three
> SoCs. And then kirkwood-6192.dtsi, kirkwood-6281.dtsi,
> kirkwood-6282.dtsi which extended that base with whatever additional
> things each SoC had.
>
> I'm wondering if something similar is needed here?
>
> armada-98DX25xx.dtsi which describes everything common to Alleycat5.
>
> armada-98DX35xx.dtsi which describes everything common to Alleycat5X,
> maybe making use of armada-98DX25xx.dtsi?.

Right now there would be no difference between 25xx and 35xx but perhaps 
having armada-98DX35xx.dtsi just #include armada-98DX25xx.dtsi would 
make the boards able to pull in something that more naturally fits the 
actual chip that is used.

> armada-98DX2538.dtsi which extends armada-98DX25xx.dtsi

There wouldn't be anything to add in 98DX2538 (at least not until we 
have a proper switchdev driver).

> And then a board file which includes armada-98DX2538.dtsi and add the
> board specific bits?
>
> I've no idea how these different devices differ, so i don't know what
> the correct hierarchy should be.

If you put aside the switch stuff they don't differ at all. Which is a 
bit different to the 98dx3236/98dx3336/98dx4251 support I added a few 
years ago where there were differences w.r.t number of CPU cores and the 
odd peripheral.

My main goal has been to get the CPU side stuff landed first. In what 
I've submitted so far I haven't tried to incorporate the switch register 
space, that's where you might see some difference like 'compatible = 
"marvell,prestera-98dx2538", "marvell,prestera";'.