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: <01b16ed0-472d-49f5-a4ad-fce03a651de8@rootcommit.com>
Date: Fri, 14 Nov 2025 13:54:58 +0000 (UTC)
From: Michael Opdenacker <michael.opdenacker@...tcommit.com>
To: Dragan Simic <dsimic@...jaro.org>
Cc: michael.opdenacker@...tcommit.com, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: add Tinkerboard 3 and 3S device
 tree

Hi Dragan,

Thanks a lot for your review and feedback!

On 11/14/25 03:26, Dragan Simic wrote:
> Hello Michael,
>
> Thanks for this patch!  Please, see some comments below.
>
> On Tuesday, November 11, 2025 18:20 CET, michael.opdenacker@...tcommit.com wrote:
>> From: Michael Opdenacker <michael.opdenacker@...tcommit.com>
>>
>> Add initial device tree support for Asus Tinkerboard 3 [1] and 3S [2],
>> which are SBCs based on the Rockchip 3566 SoC.
> For consistency and because it's a proper noun, this should be
> s/Tinkerboard/Tinker Board/.

Fixed in all the patches.

>
> The board .dts/.dtb files should include "-board", i.e. these should
> be "rk3566-tinker-board-3.dtb" and "rk3566-tinker-board-3s.dtb"
> instead, because there's no real need for shortening.  These boards
> are simply named "Tinker Board", which should be preserved.

Done too. However, I used these names for consistency with what was used 
on arm(32) for the original Tinker Board:
arch/arm/boot/dts/rockchip/rk3288-tinker.dts
arch/arm/boot/dts/rockchip/rk3288-tinker-s.dts
arch/arm/boot/dts/rockchip/rk3288-tinker.dtsi

I guess it's fine to ignore what arm did right? It won't live as long as 
arm64 (I attend Arnd's talk about arm 32).

>
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
>>   dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-tinker-3.dts b/arch/arm64/boot/dts/rockchip/rk3566-tinker-3.dts
>> new file mode 100644
>> index 000000000000..938af35b9004
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3566-tinker-3.dts
>> @@ -0,0 +1,14 @@
>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> +/*
>> + * Copyright (C) 2025 Michael Opdenacker <michael.opdenacker@...tcommit.com>
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "rk3566-tinker-3.dtsi"
> The same comment from above about the naming applies here (as well
> as in other places), so we should have "rk3566-tinker-board-3.dtsi"
> here instead.
>
>> +
>> +/ {
>> +	model = "Rockchip RK3566 Asus Tinker Board 3";
> For consistency and to avoid redundancy, the "Rockchip RK3566"
> part should be removed.


Done.

>
>> +	compatible = "asus,rk3566-tinker-3", "rockchip,rk3566";
> Actually, the compatible should be "asus,rk3566-tinker-board-3"
> instead, because there's no real need for shortening it.


No problem to do it. However, here we have a slightly bigger problem: it 
would be inconsistent with the bindings for the original Tinker Board in 
the same rockchip.yaml file:

       - description: Asus Tinker board
         items:
           - const: asus,rk3288-tinker
           - const: rockchip,rk3288

       - description: Asus Tinker board S
         items:
           - const: asus,rk3288-tinker-s
           - const: rockchip,rk3288

What do you think? The discrepancy would be quite visiible.

>> +	compatible = "asus,rk3566-tinker-3s", "asus,rk3566-tinker-3", "rockchip,rk3566";
> The compatibles should be as below instead, for the same reasons
> as already explained above.
>
>    "asus,rk3566-tinker-board-3s", "asus,rk3566-tinker-board-3", "rockchip,rk3566"

Yes, whatever is decided for the compatible strings.
>
> Though, perhaps it would be better to not include the "asus,rk3566-
> tinker-board-3" part, because I think it's pretty much redundant.


My reasoning was that Tinker Board 3S is a superset of Tinker Board 3 
(additional eMMC and headers).
If someday some code is associated to the compatible string for Tinker 
3, than Tinker 3S should use it too, right? Unless we want to have the 
possibility to ignore some Tinker3 code in Tinker 3S for some reason. 
Then, it's better indeed that 3S doesn't use the Tinker 3 compatible 
string. It seems we have more options with what you're suggesting.

What do you think?

Thanks again,
Cheers
Michael.

-- 
Michael Opdenacker
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ