linux-kernel - Re: [PATCH 03/24] arm64: dts: qcom: Introduce Glymur base dtsi and CRD dts

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: <6563611c-b7da-49b2-822b-79c5c5c67237@oss.qualcomm.com>
Date: Wed, 8 Oct 2025 17:00:53 +0530
From: Pankaj Patil <pankaj.patil@....qualcomm.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/24] arm64: dts: qcom: Introduce Glymur base dtsi and
 CRD dts

On 9/25/2025 6:32 PM, Marc Zyngier wrote:
> On Thu, 25 Sep 2025 07:32:11 +0100,
> Pankaj Patil <pankaj.patil@....qualcomm.com> wrote:
>> Introduce initial device tree support for Glymur - Qualcomm's
>> next-generation compute SoC and it's associated Compute Reference
>> Device (CRD) platform.
>>
>> The dt describes CPUs, CPU map, GCC and RPMHCC clock controllers,
>> geni UART, interrupt controller, TLMM, reserved memory,
>> interconnects, SMMU, firmware scm, watchdog, apps rsc, RPMHPD,
>> SRAM, PSCI and pmu nodes.
>>
>> Signed-off-by: Pankaj Patil <pankaj.patil@....qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/Makefile       |    1 +
>>  arch/arm64/boot/dts/qcom/glymur-crd.dts |   25 +
>>  arch/arm64/boot/dts/qcom/glymur.dtsi    | 1320 +++++++++++++++++++++++++++++++
>>  3 files changed, 1346 insertions(+)
>>
> [...]
>
>> +		intc: interrupt-controller@...00000 {
>> +			compatible = "arm,gic-v3";
>> +			reg = <0x0 0x17000000 0x0 0x10000>,
>> +			      <0x0 0x17080000 0x0 0x480000>;
>> +
>> +			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> +			#interrupt-cells = <3>;
>> +			interrupt-controller;
>> +
>> +			#redistributor-regions = <1>;
>> +			redistributor-stride = <0x0 0x40000>;
> Drop these two properties. I assume that your GIC implementation is
> compliant with the architecture, and doesn't need hand-holding.
>
>> +
>> +			#address-cells = <2>;
>> +			#size-cells = <2>;
>> +			ranges;
>> +
>> +			gic_its: gic-its@...40000 {
>> +				compatible = "arm,gic-v3-its";
>> +				reg = <0x0 0x17040000 0x0 0x40000>;
>> +
>> +				msi-controller;
>> +				#msi-cells = <1>;
>> +			};
>> +		};
> [...]
>
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
>> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
>> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
>> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
> You are missing at one interrupt here, as the CPUs have both secure
> security state and FEAT_VHE (hint: the EL2 virtual timer also has an
> interrupt, usually on PPI 12).
>
> 	M.
>
Will fix both nodes