[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <14213f52-5460-4455-9e15-739b04fda1ed@app.fastmail.com>
Date: Tue, 16 May 2023 20:41:32 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Trilok Soni" <quic_tsoni@...cinc.com>,
"Dmitry Baryshkov" <dmitry.baryshkov@...aro.org>,
"Souradeep Chowdhury" <quic_schowdhu@...cinc.com>
Cc: "Andy Gross" <agross@...nel.org>,
"Konrad Dybcio" <konrad.dybcio@...ainline.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
"Bjorn Andersson" <andersson@...nel.org>,
"Rob Herring" <robh+dt@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
"Sibi Sankar" <quic_sibis@...cinc.com>,
"Rajendra Nayak" <quic_rjendra@...cinc.com>
Subject: Re: [PATCH V6 1/3] dt-bindings: sram: qcom,imem: Add Boot Stat region within
IMEM
On Tue, May 16, 2023, at 20:34, Trilok Soni wrote:
> On 5/16/2023 1:16 AM, Arnd Bergmann wrote:
>
> To understand bit better here, what you are suggesting here that
> application bootloader (e.g., UEFI app for Linux) can read these
> boot values from the IMEM and encode them into the devicetree properties
> which can be later retrieved directly from the userspace.
I'm not entirely sure I understand the concept of "application bootloader",
but in principle this can be anything that runs before the devicetree
is handed off from the final boot loader to the kernel.
> I am fine with this approach as well and in this case we just
> need to submit the bindings document, right?
Yes, exactly.
Arnd
Powered by blists - more mailing lists