linux-hardening - Re: [PATCH 2/6] arm64: dts: qcom: sm6125-xiaomi-ginkgo: Correct reserved memory ranges

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: <d90872ae-968f-4340-8348-aa83de92a3de@ixit.cz>
Date: Fri, 16 Jan 2026 12:21:05 +0100
From: David Heidelberg <david@...t.cz>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Barnabás Czémán <barnabas.czeman@...nlining.org>,
 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>, Gabriel Gonzales <semfault@...root.org>,
 Kees Cook <kees@...nel.org>, Tony Luck <tony.luck@...el.com>,
 "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
 Biswapriyo Nath <nathbappai@...il.com>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
 phone-devel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht,
 linux@...nlining.org
Subject: Re: [PATCH 2/6] arm64: dts: qcom: sm6125-xiaomi-ginkgo: Correct
 reserved memory ranges

On 16/01/2026 10:52, Konrad Dybcio wrote:
> On 1/14/26 10:55 PM, David Heidelberg wrote:
>> On 14/01/2026 11:28, Konrad Dybcio wrote:
>>> On 1/14/26 11:15 AM, David Heidelberg wrote:
>>>> On 12/01/2026 21:13, BarnabÃ¡s CzÃ©mÃ¡n wrote:
>>>>> The device was crashing on high memory load because the reserved memory
>>>>> ranges was wrongly defined. Correct the ranges for avoid the crashes.
>>>>> Change the ramoops memory range to match with the values from the recovery
>>>>> to be able to get the results from the device.
>>>>>
>>>>> Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo")
>>>>> Signed-off-by: Barnabás Czémán <barnabas.czeman@...nlining.org>
>>>>> ---
>>>
>>> [...]
>>>
>>>> Hello!
>>>>
>>>> I suggest one more nice to have improvement:
>>>>
>>>> you could label framebuffer cont_splash_mem since you already touching the node and testing the series.
>>>>
>>>> Then in additional commit, you can replace manually defined `reg` in chosen > framebuffer node with
>>>>
>>>> memory-region = <&cont_splash_mem>;
>>>>
>>>> For example you can look at sdm845-oneplus-common.dtsi
>>>>
>>>> Tell me what u think
>>>
>>> If you wanna do that, please call it framebuffer_mem, "cont_splash" is a
>>> Qualcomm-specific name for (roughly) flicker-free bootup
>>
>> I have feeling someone recommended me to stick with cont_splash_mem.
>>
>> I think, since we'll be doing the mdss reset anyway in sdm845 (which I used as an example), I can do the rename in our sdm845 too then without any harm? (no it's not flicker-free takeover :D )
> 
> It's not flicker-free because the OS must cooperate in that process,
> whereas we currently reset and re-initialize the entire display subsystem

Sure.

Previously I was thinking, that after doing proper panel driver with 
proper initialization sequences etc. etc., we could have device-tree 
property such as "linux,takeover-from-bootloader", where we could skip 
mdss reset, panel reset and just continue from the point what bootloader 
set (for devices where bootloader does the right job).

David

> 
> Konrad

-- 
David Heidelberg