linux-kernel - Re: [PATCH v2 6/8] arm64: dts: bst: add support for Black Sesame Technologies C1200 CDCU1.0 board

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: <20250702141957.GA1416711-robh@kernel.org>
Date: Wed, 2 Jul 2025 09:19:57 -0500
From: Rob Herring <robh@...nel.org>
To: Albert Yang <yangzh0906@...ndersoft.com>
Cc: krzk@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/8] arm64: dts: bst: add support for Black Sesame
 Technologies C1200 CDCU1.0 board

On Wed, Jul 02, 2025 at 08:31:33PM +0800, Albert Yang wrote:
> Hi Krzysztof,
> 
> Thank you for your detailed review and feedback. I have addressed all the issues you mentioned:
> 
> > This is messed. SoB does not go to changelog. Apply your patch and look
> > at result - do you see SoB? No, because changelog is stripped.
> > submitting patches explains how this is supposed to look like.
> 
> Fixed. Moved Signed-off-by lines to the correct position in commit message, 
> outside of the changelog section.
> 
> > Nothing improved. I asked to follow DTS coding style in ordering.
> 
> Fixed. Reordered all nodes according to DTS coding style:
> - Root level nodes: alphabetically ordered (clk_mmc → cpus → psci → soc → timer)
> - SoC nodes: ordered by address (uart0@...08000 → mmc0@...00000 → gic@...00000)
> - Applied consistent ordering throughout the dtsi file
> 
> > l2-cache. Otherwise it is incomplete, so add the second one.
> 
> Fixed. Renamed l2-cache-1 to l2-cache as per standard naming convention.
> 
> > Why do you have multiple memory nodes, not one?
> 
> Fixed. Consolidated multiple memory nodes into a single memory node with 
> multiple reg entries as required by Device Tree specification:
> 
> Before (incorrect):
>   memory@...151000 { reg = <0x8 0x00151000 0x0 0x1000>; };
>   memory@...254000 { reg = <0x8 0x00254000 0x0 0x1000>; };
>   ...
> 
> After (correct):
>   memory@...151000 {
>     reg = <0x8 0x00151000 0x0 0x1000>,
>           <0x8 0x00254000 0x0 0x1000>,

These are very odd. Are these really main memory vs. some on chip SRAM 
or some other specific purpose? 

A 4KB block doesn't really work if the OS uses 16 or 64KB pages, but I 
guess that would be up to the OS to ignore them.

>           <0x8 0x10000000 0x0 0x30000000>,
>           <0x8 0xc0000000 0x1 0x0>,
>           <0xc 0x00000000 0x0 0x40000000>;
>   };