[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALHNRZ-aj+rR0qFuiU+cPNsHWQgMJ2mMjzysJudY-TPN9tY3gg@mail.gmail.com>
Date: Mon, 2 Feb 2026 22:25:23 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.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 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?
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.
Aaron
Powered by blists - more mailing lists