[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0da3c96e-4f20-4bd0-836e-73d20581954f@ixit.cz>
Date: Wed, 14 Jan 2026 22:55:40 +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 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 )
David
>
> Konrad
--
David Heidelberg
Powered by blists - more mailing lists