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: <0DC5CC32-231A-4802-9A69-7BCBB21066E1@lucaweiss.eu>
Date: Sat, 21 Jun 2025 12:53:11 +0200
From: Luca Weiss <luca@...aweiss.eu>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 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+



Konrad Dybcio <konrad.dybcio@....qualcomm.com> schreef op 21 juni 2025 12:11:00 CEST:
>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;

Huh, why this mix'n'match in this SoC... Fun

Then Cristian, disregard my email please :)

>
>
>Konrad