linux-kernel - Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

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: <CALHNRZ_uWJRWEfwW_NjdBcWSf_NTYWLg6DJGAyH0-KmonUQFXg@mail.gmail.com>
Date: Tue, 3 Feb 2026 21:15: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 Tue, Feb 3, 2026 at 3:28 AM Konrad Dybcio
<konrad.dybcio@....qualcomm.com> wrote:
>
> 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 { ... };

I verified this by tacking the label to the chosen node in the sm8550
dtsi and abl carried on just fine. If this doesn't get a blocking
comment in the next day or so, I'll drop these two tz-log commits, and
fold this into the 'fix dtbos' patch, and send a v2.

Aaron