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] [day] [month] [year] [list]
Message-ID: <d88df311-9ec5-9552-7b12-2db88b99b434@gmail.com>
Date:   Fri, 18 Jun 2021 18:30:10 +0200
From:   Alex Bee <knaerzche@...il.com>
To:     Heiko Stübner <heiko@...ech.de>
Cc:     devicetree@...r.kernel.org, balbi@...nel.org,
        gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
        robh+dt@...nel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/3] arm64: dts: rockchip: Add RK3399 Rock Pi 4a plus
 board

Hi Heiko,

Am 18.06.21 um 15:08 schrieb Heiko Stübner:
> Am Donnerstag, 17. Juni 2021, 06:49:54 CEST schrieb Alex Bee:
>> Rock Pi 4a plus board is the successor of Rock Pi 4a board.
>>
>> Differences to the original version are
>> - has RK3399 OP1 SoC revision
>> - has eMMC (16 or 32 GB) soldered on board (no changes required,
>>    since it is enabled in rk3399-rock-pi-4.dtsi)
>> - dev boards have SPI flash soldered, but as per manufacturer response,
>>    this won't be the case for mass production boards
>>
>> I didn't add yet another compatible, since the small set of differences
>> are captured by the device tree.
>>
>> Signed-off-by: Alex Bee <knaerzche@...il.com>
>> ---
>>   arch/arm64/boot/dts/rockchip/Makefile              |  1 +
>>   .../boot/dts/rockchip/rk3399-rock-pi-4a-plus.dts   | 14 ++++++++++++++
>>   2 files changed, 15 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a-plus.dts
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
>> index c3e00c0e2db7..dbd7d37950f1 100644
>> --- a/arch/arm64/boot/dts/rockchip/Makefile
>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
>> @@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc-mezzanine.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4a.dtb
>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4a-plus.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4b.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4c.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a-plus.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a-plus.dts
>> new file mode 100644
>> index 000000000000..2deaab7f9307
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a-plus.dts
>> @@ -0,0 +1,14 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2019 Akash Gajjar <Akash_Gajjar@...tor.com>
>> + * Copyright (c) 2019 Pragnesh Patel <Pragnesh_Patel@...tor.com>
>> + */
>> +
>> +/dts-v1/;
>> +#include "rk3399-rock-pi-4.dtsi"
>> +#include "rk3399-op1-opp.dtsi"
>> +
>> +/ {
>> +	model = "Radxa ROCK Pi 4A plus";
>> +	compatible = "radxa,rockpi4a", "radxa,rockpi4", "rockchip,rk3399";
> hmm, I don't really follow why you're re-using the radxa,rockpi4a
> compatible. I'd assume this should be radxa,rockpi4a+ or something?

Ah, yes this was part of my cover letter, which obviously got lost 
somewhere.

Anyways: Reason I thought of was: For example broadcom nvram file names 
must match the compatible string and they have to be copied/symlinked 
over and over if we add new compatibles for every minor changed revision 
of a board. I guess there are more examples for that in userland.

>
> I.e. if a bootloader needs to select the matching devicetree from a list
> of available devicetrees, this could end up running a regular rockpi4a
> (without +) using the OP1 operating points and thus at way too high
> frequencies.

Besides I wasn't aware, that "a bootloader" can do that already I 
understand your concerns and will change it.

Alex.

>
> Heiko
>
>
>> +};
>>
>
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ