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]
Date:   Wed, 9 Aug 2023 00:02:00 +0530
From:   Apurva Nandan <a-nandan@...com>
To:     Nishanth Menon <nm@...com>
CC:     Vignesh Raghavendra <vigneshr@...com>,
        Tero Kristo <kristo@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Udit Kumar <u-kumar1@...com>, Hari Nagalla <hnagalla@...com>,
        Dasnavis Sabiya <sabiya.d@...tralsolutions.com>,
        Tom Rini <trini@...sulko.com>
Subject: Re: [PATCH v2 1/4] arm64: dts: ti: k3-j784s4-main: Add bootph-pre-ram
 property for SPL nodes

Hi Nishanth,

On 08/08/23 00:37, Nishanth Menon wrote:
> On 00:26-20230808, Apurva Nandan wrote:
>> Add bootph-pre-ram property for all the nodes used in SPL stage,
>> for syncing it later to u-boot j784s4 dts.
>>
>> Signed-off-by: Apurva Nandan <a-nandan@...com>
>> ---
> We need to rework this a little more:
>
> The approach taken in this series is enable pre-ram for everything. I am
> not sure that is the right direction.
These patches only enable bootph-pre-ram for the nodes, that already had 
bootph-pre-ram property in u-boot dts
patches for j784s4. And these are selected after removing unnecessary 
nodes that had this property, so not added for
everything. Are there a nodes which seem to have unnecessary 
bootph-pre-ram property according to you, need to remove?
> https://github.com/devicetree-org/dt-schema/blob/e87ba2f515392c2a4694642063efb43023331ff6/dtschema/schemas/bootph.yaml#L70
>
> patch #1: board generic changes: patch #1
> patch #2-: board specific change (per board)
>
> Make sure you use the correct property and document why this is needed
> in the section added as well - esp for board generic changes introduced
> into SoC.dtsi files.
>
I am little unclear about what nodes you refer with board generic vs 
board specific bootph-pre-ram.
I have currently added bootph-pre-ram in board EVM dts files if the node 
is disabled in SoC dtsi and enabled
in EVM dts (no point adding bootph-pre-ram in disabled node), or for 
pinmuxes, etc. What is the segregation
you want in the patch, do you want some bootph-pre-ram to be moved from 
where they are?
>>   arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> index 2ea0adae6832..aaec569fe91a 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> @@ -6,6 +6,7 @@
>>    */
>>   
>>   &cbass_main {
>> +	bootph-pre-ram;
> Is this better done where the node is defined?
Okay, this I will fix.
>
>>   	msmc_ram: sram@...00000 {
>>   		compatible = "mmio-sram";
>>   		reg = <0x00 0x70000000 0x00 0x800000>;
>> @@ -670,6 +671,7 @@ main_sdhci1: mmc@...0000 {
>>   	};
>>   
>>   	main_navss: bus@...00000 {
>> +		bootph-pre-ram;
>>   		compatible = "simple-bus";
>>   		#address-cells = <2>;
>>   		#size-cells = <2>;
>> @@ -705,6 +707,7 @@ main_udmass_inta: msi-controller@...00000 {
>>   		};
>>   
>>   		secure_proxy_main: mailbox@...00000 {
>> +			bootph-pre-ram;
>>   			compatible = "ti,am654-secure-proxy";
>>   			#mbox-cells = <1>;
>>   			reg-names = "target_data", "rt", "scfg";
>> -- 
>> 2.34.1
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ