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: <3dd41426-c026-a832-0a6b-0aabfaec2a8c@quicinc.com>
Date:   Wed, 29 Nov 2023 14:55:40 +0530
From:   Sibi Sankar <quic_sibis@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>, <andersson@...nel.org>,
        <robh+dt@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <catalin.marinas@....com>, <ulf.hansson@...aro.org>
CC:     <agross@...nel.org>, <conor+dt@...nel.org>,
        <ayan.kumar.halder@....com>, <j@...nau.net>,
        <dmitry.baryshkov@...aro.org>, <nfraprado@...labora.com>,
        <m.szyprowski@...sung.com>, <u-kumar1@...com>, <peng.fan@....com>,
        <lpieralisi@...nel.org>, <quic_rjendra@...cinc.com>,
        <abel.vesa@...aro.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <quic_tsoni@...cinc.com>,
        <neil.armstrong@...aro.org>
Subject: Re: [PATCH V2 3/5] arm64: dts: qcom: Add base X1E80100 dtsi and the
 QCP dts



On 11/18/23 06:36, Konrad Dybcio wrote:
> On 17.11.2023 12:39, Sibi Sankar wrote:
>> From: Rajendra Nayak <quic_rjendra@...cinc.com>
>>
>> Add base dtsi and QCP board (Qualcomm Compute Platform) dts file for
>> X1E80100 SoC, describing the CPUs, GCC and RPMHCC clock controllers,
>> geni UART, interrupt controller, TLMM, reserved memory, interconnects,
>> SMMU and LLCC nodes.
>>
>> Co-developed-by: Abel Vesa <abel.vesa@...aro.org>
>> Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
>> Signed-off-by: Rajendra Nayak <quic_rjendra@...cinc.com>
>> Co-developed-by: Sibi Sankar <quic_sibis@...cinc.com>
>> Signed-off-by: Sibi Sankar <quic_sibis@...cinc.com>
>> ---
> [...]
> 
>> +&tlmm {
>> +	gpio-reserved-ranges = <33 3>, <44 4>, /* SPI (TPM) */
> Surely SPI doesn't use 7 wires! :D

yeah, they are just secure reserved unused gpios.

> 
> [...]
> 
>> +			L2_0: l2-cache-0 {
> the cache device is distinguishable by its parent, so "l2-cache" is enough

thanks will fix ^^

> 
> 
>> +				compatible = "cache";
>> +				cache-level = <2>;
>> +				cache-unified;
>> +			};
>> +		};
>> +
> [...]
> 
>> +		idle-states {
>> +			entry-method = "psci";
>> +
>> +			CLUSTER_C4: cpu-sleep-0 {
>> +				compatible = "arm,idle-state";
>> +				idle-state-name = "ret";
>> +				arm,psci-suspend-param = <0x00000004>;
> These suspend parameters look funky.. is this just a PSCI sleep
> implementation that strays far away from Arm's suggested guidelines?

not really! it's just that 30th bit is set according to spec i.e
it's marked as a retention state.

> 
> [...]
> 
> 
>> +		CPU_PD11: power-domain-cpu11 {
>> +			#power-domain-cells = <0>;
>> +			power-domains = <&CLUSTER_PD>;
>> +		};
>> +
>> +		CLUSTER_PD: power-domain-cpu-cluster {
>> +			#power-domain-cells = <0>;
>> +			domain-idle-states = <&CLUSTER_CL4>, <&CLUSTER_CL5>;
>> +		};
> So, can the 3 clusters not shut down their L2 and PLLs (if separate?)
> on their own?

on CL5 the clusters are expected to shutdown their l2 and PLL on their
own.

> 
>> +	};
>> +
>> +	reserved-memory {
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		gunyah_hyp_mem: gunyah-hyp@...00000 {
>> +			reg = <0x0 0x80000000 0x0 0x800000>;
>> +			no-map;
>> +		};
>> +
>> +		hyp_elf_package_mem: hyp-elf_package@...00000 {
> no underscores in node names, use hyphens

ack

-Sibi
> 
> The rest looks OK I think
> 
> Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ