| 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
| ||
|
Date: Tue, 23 May 2023 12:28:58 -0700
From: Brad Larson <blarson@....com>
To: <michal.simek@....com>
CC: <adrian.hunter@...el.com>, <alcooperx@...il.com>,
<andy.shevchenko@...il.com>, <arnd@...db.de>, <blarson@....com>,
<brendan.higgins@...ux.dev>, <briannorris@...omium.org>,
<broonie@...nel.org>, <catalin.marinas@....com>,
<conor+dt@...nel.org>, <davidgow@...gle.com>,
<devicetree@...r.kernel.org>, <fancer.lancer@...il.com>,
<gerg@...ux-m68k.org>, <gsomlo@...il.com>,
<hal.feng@...rfivetech.com>, <hasegawa-hitomi@...itsu.com>,
<j.neuschaefer@....net>, <joel@....id.au>, <kernel@...il.dk>,
<krzk@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
<lee.jones@...aro.org>, <lee@...nel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <linux-mmc@...r.kernel.org>,
<linux-spi@...r.kernel.org>, <p.zabel@...gutronix.de>,
<rdunlap@...radead.org>, <robh+dt@...nel.org>,
<samuel@...lland.org>, <skhan@...uxfoundation.org>,
<suravee.suthikulpanit@....com>, <thomas.lendacky@....com>,
<tonyhuang.sunplus@...il.com>, <ulf.hansson@...aro.org>,
<vaishnav.a@...com>, <walker.chen@...rfivetech.com>,
<will@...nel.org>, <zhuyinbo@...ngson.cn>
Subject: Re: [PATCH v14 6/8] arm64: dts: Add AMD Pensando Elba SoC support
Hi Michal,
Thanks for reviewing the patch.
On 5/16/23 09:54, Michal Simek wrote:
> On 5/15/23 20:16, Brad Larson wrote:
>> Add AMD Pensando common and Elba SoC specific device nodes
>>
>> Signed-off-by: Brad Larson <blarson@....com>
>> ---
>>
>> v14 changes:
>> - Fix dtbs_check l2-cache* property issue by adding required
>> cache-level and cache-unified properties
>> - Observed the issue after updating dtschema from 2023.1 to 2023.4
>> and yamllint from 1.26.3 to 1.30.0
>>
>> v11 changes:
>> - Delete reset-names
>> - Fix spi0 compatible to be specific 'amd,pensando-elba-ctrl'
>>
>> v9 changes:
>> - Single node for spi0 system-controller and squash
>> the reset-controller child into parent
>>
>> ---
>> arch/arm64/boot/dts/amd/Makefile | 1 +
>> arch/arm64/boot/dts/amd/elba-16core.dtsi | 197 ++++++++++++++++++
>> arch/arm64/boot/dts/amd/elba-asic-common.dtsi | 80 +++++++
>> arch/arm64/boot/dts/amd/elba-asic.dts | 28 +++
>> arch/arm64/boot/dts/amd/elba-flash-parts.dtsi | 106 ++++++++++
>> arch/arm64/boot/dts/amd/elba.dtsi | 191 +++++++++++++++++
>> 6 files changed, 603 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/amd/elba-16core.dtsi
>> create mode 100644 arch/arm64/boot/dts/amd/elba-asic-common.dtsi
>> create mode 100644 arch/arm64/boot/dts/amd/elba-asic.dts
>> create mode 100644 arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
>> create mode 100644 arch/arm64/boot/dts/amd/elba.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
>> index 68103a8b0ef5..8502cc2afbc5 100644
>> --- a/arch/arm64/boot/dts/amd/Makefile
>> +++ b/arch/arm64/boot/dts/amd/Makefile
>> @@ -1,2 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0
>> +dtb-$(CONFIG_ARCH_PENSANDO) += elba-asic.dtb
>> dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
>> diff --git a/arch/arm64/boot/dts/amd/elba-16core.dtsi b/arch/arm64/boot/dts/amd/elba-16core.dtsi
>> new file mode 100644
>> index 000000000000..f9f9f5fd5f69
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/amd/elba-16core.dtsi
>> @@ -0,0 +1,197 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +/*
>> + * Copyright 2020-2022 Advanced Micro Devices, Inc.
>
> 2023 and the same below.
I'll update the copyright in the next submit
>> + */
>> +
>> +/ {
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu-map {
>> + cluster0 {
>> + core0 { cpu = <&cpu0>; };
>> + core1 { cpu = <&cpu1>; };
>> + core2 { cpu = <&cpu2>; };
>> + core3 { cpu = <&cpu3>; };
>> + };
>> +
>> + cluster1 {
>> + core0 { cpu = <&cpu4>; };
>> + core1 { cpu = <&cpu5>; };
>> + core2 { cpu = <&cpu6>; };
>> + core3 { cpu = <&cpu7>; };
>> + };
>> +
>> + cluster2 {
>> + core0 { cpu = <&cpu8>; };
>> + core1 { cpu = <&cpu9>; };
>> + core2 { cpu = <&cpu10>; };
>> + core3 { cpu = <&cpu11>; };
>> + };
>> +
>> + cluster3 {
>> + core0 { cpu = <&cpu12>; };
>> + core1 { cpu = <&cpu13>; };
>> + core2 { cpu = <&cpu14>; };
>> + core3 { cpu = <&cpu15>; };
>> + };
>> + };
>> +
>> + /* CLUSTER 0 */
>> + cpu0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a72";
>> + reg = <0 0x0>;
>
> Do you really need 2/0 split here. The first cell is 0 anyway.
Yes following 64-bit system definition
...
>> diff --git a/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi b/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
>> new file mode 100644
>> index 000000000000..734893fef2c3
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
>> @@ -0,0 +1,106 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +/*
>> + * Copyright 2020-2022 Advanced Micro Devices, Inc.
>> + */
>> +
>> +&flash0 {
0xf0000>> + partitions {
>> + compatible = "fixed-partitions";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + partition@0 {
>> + label = "flash";
>> + reg = <0x10000 0xfff0000>;
>
> This doesn't fit with partition@0 above.
> Also size is weird.
This is intended to not expose sector 0.
>> + };
>> +
>> + partition@...00 {
>> + label = "golduenv";
>> + reg = <0xf0000 0x10000>;
>> + };
>> +
>> + partition@...000 {
>> + label = "boot0";
>> + reg = <0x100000 0x80000>;
>> + };
>> +
>> + partition@...000 {
>> + label = "golduboot";
>> + reg = <0x180000 0x200000>;
>> + };
>> +
>> + partition@...000 {
>> + label = "brdcfg0";
>> + reg = <0x380000 0x10000>;
>> + };
>> +
>> + partition@...000 {
>> + label = "brdcfg1";
>> + reg = <0x390000 0x10000>;
>> + };
>> +
>> + partition@...000 {
>> + label = "goldfw";
>> + reg = <0x400000 0x3c00000>;
>
> This size looks weird.
It's the allocated size for this firmware component.
>> + };
>> +
>> + partition@...0000 {
>> + label = "fwmap";
>> + reg = <0x4010000 0x20000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "fwsel";
>> + reg = <0x4030000 0x20000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "bootlog";
>> + reg = <0x4090000 0x20000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "panicbuf";
>> + reg = <0x40b0000 0x20000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "uservars";
>> + reg = <0x40d0000 0x20000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "uboota";
>> + reg = <0x4200000 0x400000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "ubootb";
>> + reg = <0x4600000 0x400000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "mainfwa";
>> + reg = <0x4a00000 0x1000000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "mainfwb";
>> + reg = <0x5a00000 0x1000000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "diaguboot";
>> + reg = <0x6a00000 0x400000>;
>> + };
>> +
>
> here is gap
This is intentional for unallocated space. I'll put in a 'spare' partition.
>> + partition@...0000 {
>> + label = "diagfw";
>> + reg = <0x8000000 0x7fe0000>;
>> + };
>> +
>> + partition@...0000 {
>> + label = "ubootenv";
>> + reg = <0xffe0000 0x10000>;
>> + };
>
> And this is missing space description.
space description?
Regards,
Brad
Powered by blists - more mailing lists