[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <74380f3e-eb76-4fb8-a1a5-d2151fb410f6@oss.qualcomm.com>
Date: Tue, 3 Feb 2026 10:28:49 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Aaron Kling <webgeek1234@...il.com>
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>,
Kumar Sharma <quic_vksharma@...cinc.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Lei Chen <quic_chenlei@...cinc.com>
Subject: Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node
On 2/3/26 5:25 AM, Aaron Kling wrote:
> On Fri, Jan 30, 2026 at 4:59 AM Konrad Dybcio
> <konrad.dybcio@....qualcomm.com> wrote:
>>
>> On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
>>> From: Lei Chen <quic_chenlei@...cinc.com>
>>>
>>> Add DT node to enable tz-log driver.
>>>
>>> Signed-off-by: Lei Chen <quic_chenlei@...cinc.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@...il.com>
>>> ---
>>
>> It's nice that you preserved the original authorship.
>>
>> Please extend the rather lackluster commit message to explain the
>> "why", which is notably different from the original downstream
>> addition, since your goal here is to mainly appease a grumpy
>> bootloader.
>>
>>> arch/arm64/boot/dts/qcom/sm8550.dtsi | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..740e3c238e8ed0f162dd168291f6e307ace66e80 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> @@ -5136,6 +5136,14 @@ data-pins {
>>> };
>>> };
>>>
>>> + qcom_tzlog: tz-log@...aa720 {
>>
>> If we were to implement qcom,tz-log upstream, this would definitely
>> not be a node randomly in the middle of /soc, rather a child of
>> imem, most likely.
>>
>> Could you please check whether adding a qcom_tzlog label to *any*
>> node makes the BL happy enough? Does it need the properties that
>> this node has?
>
> It does appear that ABL doesn't care about the path name, only the
> label. And given that the original change that worked had the label
> pointing at an empty node, it doesn't fail if all the properties are
> missing. I moved the node underneath an sram node and the bootloader
> loaded my dtbo just fine.
>
> The imem/sram node, though... The numbers don't add up. Per the
> downstream dt, qcom,msm-imem@...aa000 has size 0x1000. Then
> tz-log@...AA720 has size 0x3000. Which... starts within the imem
> range, then blasts quite far outside of it. So... what should this end
> up looking like?
The real SYSTEM_IMEM range is base=0x14680000 len=0x2c000, not all of
which is accessible to the OS
Perhaps it's high time for me to respin:
https://lore.kernel.org/linux-arm-msm/20250523-topic-ipa_mem_dts-v1-9-f7aa94fac1ab@oss.qualcomm.com/
> I should also note that an empty node at /soc@...z-log fails dt schema
> checks. I presume that adding any warnings would immediately get a
> patch nuked from orbit, which is why I fetched a real binding and node
> from CLO.
I don't know if that'll be acceptable by others, but if all we need
is a label *somewhere*, I wouldn't be totally opposed to doing something
like:
/* The bootloader fails to apply DTBOs if this specific label is absent */
qcom_tzlog: aliases { ... };
Konrad
Powered by blists - more mailing lists