linux-kernel - Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

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: <f83cc435-7736-4003-b5b2-a84e2fe725c6@oss.qualcomm.com>
Date: Sat, 21 Jun 2025 12:11:00 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Luca Weiss <luca@...aweiss.eu>, cristian_ci <cristian_ci@...tonmail.com>,
        "robh@...nel.org" <robh@...nel.org>,
        "krzk+dt@...nel.org"
 <krzk+dt@...nel.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "andersson@...nel.org" <andersson@...nel.org>,
        "konradybcio@...nel.org" <konradybcio@...nel.org>
Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "~postmarketos/upstreaming@...ts.sr.ht"
 <~postmarketos/upstreaming@...ts.sr.ht>,
        "phone-devel@...r.kernel.org" <phone-devel@...r.kernel.org>
Subject: Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for
 Billion Capture+

On 6/21/25 11:27 AM, Luca Weiss wrote:
> On 21-06-2025 9:07 a.m., cristian_ci wrote:
>> On Saturday, June 21st, 2025 at 00:20, Luca Weiss <luca@...aweiss.eu> wrote:
>>
>>>> +
>>>> + reserved-memory {
>>>> + qseecom@0 {
>>>
>>>
>>> qseecom@...00000 ?
>>>
>>>> + reg = <0x00 0x84a00000 0x00 0x1900000>;
>>>> + no-map;
>>>> + };
>>
>> Looking at downstream devicetree, every reserved-memory nodes with "removed-dma-pool" compatible has unit address 0. OTOH, kernel documentation [1] says:
>> "  Following the generic-names recommended practice, node names should
>>    reflect the purpose of the node (ie. "framebuffer" or "dma-pool").
>>    Unit address (@<address>) should be appended to the name if the node
>>    is a static allocation."
>>
>> In my case, downstream devicetree shows:
>>
>>         other_ext_region@0 {
>>             compatible = "removed-dma-pool";
>>             no-map;
>>             reg = <0x00 0x84a00000 0x00 0x1e00000>;
>>         };
>>
>> which will be 'qseecom' reserved-memory node in mainline devicetree.
>>
>> OTOH, 'qseecom' node in downstream devicetree also shows:
>>
>>         qseecom@...00000 {
>>             compatible = "qcom,qseecom";
>>             reg = <0x84a00000 0x1900000>;
>>                          ...
>>
>> If you confirm what you suggest, 'qseecom' reserved-memory node will look like the following:
>>
>>         qseecom_mem: qseecom@...00000 {
>>             reg = <0x0 0x84a00000 0x0 0x1900000>;
>>             no-map;
>>         };
>>
>> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> 
> The name (qseecom@...00000) mostly does not matter at runtime, it's just a nice label we give it. The reg is the important bit that gets used in reserved-memory.
> 
> But actually re-checking, I don't think your reserved-memory works right now, msm8953.dtsi has
> 
>     soc: soc@0 {
>         #address-cells = <1>;
>         #size-cells = <1>;
> 
> which means that you should only have one value for address, and one for size, so "reg = <0x84a00000 0x1900000>;". This is different to most other Qualcomm arm64 SoCs.

reserved-memory {
                #address-cells = <2>;
                #size-cells = <2>;
                ranges;


Konrad