Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node
From: Aaron Kling
Date: Tue Feb 03 2026 - 22:16:12 EST
On Tue, Feb 3, 2026 at 3:28 AM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 2/3/26 5:25 AM, Aaron Kling wrote:
> > On Fri, Jan 30, 2026 at 4:59 AM Konrad Dybcio
> > <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> >>
> >> On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
> >>> From: Lei Chen <quic_chenlei@xxxxxxxxxxx>
> >>>
> >>> Add DT node to enable tz-log driver.
> >>>
> >>> Signed-off-by: Lei Chen <quic_chenlei@xxxxxxxxxxx>
> >>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> >>> ---
> >>
> >> 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@146aa720 {
> >>
> >> 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@146aa000 has size 0x1000. Then
> > tz-log@146AA720 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@xxxxxxxxxxxxxxxx/
>
> > I should also note that an empty node at /soc@0/tz-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