[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f144e9bf-decd-42e8-b87d-d511552ab6e1@oss.qualcomm.com>
Date: Wed, 4 Feb 2026 13:39:43 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Mukesh Ojha <mukesh.ojha@....qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@....qualcomm.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
Guenter Roeck
<linux@...ck-us.net>,
Rajendra Nayak <quic_rjendra@...cinc.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org
Subject: Re: [PATCH v6 5/5] arm64: dts: qcom: ipq5424: add support to get
watchdog bootstatus from IMEM
On 2/2/26 2:44 PM, Mukesh Ojha wrote:
> On Sat, Jan 31, 2026 at 10:18:29AM +0200, Dmitry Baryshkov wrote:
>> On Fri, Jan 30, 2026 at 04:14:34PM +0530, Kathiravan Thirumoorthy wrote:
>>> Add the "sram" property to the watchdog device node to enable
>>> retrieval of the system restart reason from IMEM, populated by XBL.
>>> Parse this information in the watchdog driver and update the bootstatus
>>> sysFS if the restart was triggered by a watchdog timeout.
>>>
>>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@....qualcomm.com>
>>> ---
>>> Changes in v6:
>>> - Update the 'sram' property to point to the SRAM region
>>> Changes in v5:
>>> - Rename the property 'qcom,imem' to 'sram'
>>> Changes in v4:
>>> - New patch
>>> ---
>>> arch/arm64/boot/dts/qcom/ipq5424.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
>
>
> I have a few more cookies (stored in a fixed IMEM location supported
> downstream) that I want to add, and they are available on all Qualcomm
> mobile SoCs. Should it be added under SMEM now?
FWIW currently they won't be probed (if you wanted to give them a compatible
string and bind a driver based on that), since drivers/misc/sram.c lacks an
of_platform_populate(), but that's trivial to change
I think getting agreement on dt-bindings may be the tougher part..
Are the cookies you want to use attached to any other part of the hardware
(e.g. in case of pil-info it's directly connected to the rprocs), or are
they general debug information?
Konrad
Powered by blists - more mailing lists