linux-kernel - Re: [PATCH 13/16] arm64: dts: qcom: msm8998: Update reserved memory map

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]
Message-ID: <0101016e83a2b64f-7d9f9170-7720-4198-adae-7f39a846c432-000000@us-west-2.amazonses.com>
Date:   Tue, 19 Nov 2019 12:28:29 +0000
From:   sibis@...eaurora.org
To:     Jeffrey Hugo <jeffrey.l.hugo@...il.com>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Rob Herring <robh+dt@...nel.org>,
        Jonathan Marek <jonathan@...ek.ca>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Mark Rutland <mark.rutland@....com>, p.zabel@...gutronix.de,
        MSM <linux-arm-msm@...r.kernel.org>,
        linux-remoteproc@...r.kernel.org,
        DTML <devicetree@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Andy Gross <agross@...nel.org>,
        linux-remoteproc-owner@...r.kernel.org
Subject: Re: [PATCH 13/16] arm64: dts: qcom: msm8998: Update reserved memory
 map

Hey Jeff,
Thanks for taking time to review
the series.

On 2019-11-19 03:34, Jeffrey Hugo wrote:
> On Mon, Nov 18, 2019 at 2:45 PM Sibi Sankar <sibis@...eaurora.org> 
> wrote:
>> 
>> Update existing and add missing regions to the reserved memory map, as
>> described in version 7.1
>> 
>> Signed-off-by: Sibi Sankar <sibis@...eaurora.org>
>> ---
>>  arch/arm64/boot/dts/qcom/msm8998.dtsi | 62 
>> ++++++++++++++++++++++++---
>>  1 file changed, 55 insertions(+), 7 deletions(-)
>> 
>> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
>> b/arch/arm64/boot/dts/qcom/msm8998.dtsi
>> index fc7838ea9a010..707673e3cf28a 100644
>> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
>> @@ -28,8 +28,13 @@
>>                 #size-cells = <2>;
>>                 ranges;
>> 
>> -               memory@...00000 {
>> -                       reg = <0x0 0x85800000 0x0 0x800000>;
>> +               hyp_mem: memory@...00000 {
>> +                       reg = <0x0 0x85800000 0x0 0x600000>;
>> +                       no-map;
>> +               };
>> +
>> +               xbl_mem: memory@...00000 {
> 
> Are we ever going to use this label?

just leaving it here for info with the
added benefit of being deleteable
if MSM8998 uses a different boot chain
where xbl_mem/tz_mem remains unused as
in the case of Cheza

> 
>> +                       reg = <0x0 0x85e00000 0x0 0x100000>;
>>                         no-map;
>>                 };
>> 
>> @@ -38,21 +43,64 @@
>>                         no-map;
>>                 };
>> 
>> -               memory@...00000 {
>> +               tz_mem: memory@...00000 {
> 
> Again, are we ever going to use this?

ditto

> 
>>                         reg = <0x0 0x86200000 0x0 0x2d00000>;
>>                         no-map;
>>                 };
>> 
>> -               rmtfs {
>> +               rmtfs_mem: memory@...00000 {
>>                         compatible = "qcom,rmtfs-mem";
>> -
>> -                       size = <0x0 0x200000>;
>> -                       alloc-ranges = <0x0 0xa0000000 0x0 0x2000000>;
>> +                       reg = <0x0 0x88f00000 0x0 0x200000>;
> 
> This seems to overlap with a defined region in the memory map.
> 0x9fa00000 seems to be a better address.

just following the what we did
for SDM845 SoC 0x88f00000 should
be safe to use.

> 
>>                         no-map;
>> 
>>                         qcom,client-id = <1>;
>>                         qcom,vmid = <15>;
>>                 };
>> +
>> +               spss_mem: memory@...00000 {
>> +                       reg = <0x0 0x8ab00000 0x0 0x700000>;
>> +                       no-map;
>> +               };
>> +
>> +               adsp_mem: memory@...00000 {
>> +                       reg = <0x0 0x8b200000 0x0 0x1a00000>;
>> +                       no-map;
>> +               };
>> +
>> +               mpss_mem: memory@...00000 {
>> +                       reg = <0x0 0x8cc00000 0x0 0x7000000>;
>> +                       no-map;
>> +               };
>> +
>> +               venus_mem: memory@...00000 {
>> +                       reg = <0x0 0x93c00000 0x0 0x500000>;
>> +                       no-map;
>> +               };
>> +
>> +               mba_mem: memory@...00000 {
>> +                       reg = <0x0 0x94100000 0x0 0x200000>;
>> +                       no-map;
>> +               };
>> +
>> +               slpi_mem: memory@...00000 {
>> +                       reg = <0x0 0x94300000 0x0 0xf00000>;
>> +                       no-map;
>> +               };
>> +
>> +               ipa_fw_mem: memory@...00000 {
>> +                       reg = <0x0 0x95200000 0x0 0x10000>;
>> +                       no-map;
>> +               };
>> +
>> +               ipa_gsi_mem: memory@...10000 {
>> +                       reg = <0x0 0x95210000 0x0 0x5000>;
>> +                       no-map;
>> +               };
>> +
>> +               gpu_mem: memory@...15000 {
>> +                       reg = <0x0 0x95215000 0x0 0x1000>;
> 
> This is the wrong size for the zap region.

double checked the memory maps,
gpu mem size is mentioned as 4kb
is that not the case?


> 
>> +                       no-map;
>> +               };
>>         };
>> 
>>         clocks {
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>>