Re: [PATCH v6 5/5] arm64: dts: qcom: ipq5424: add support to get watchdog bootstatus from IMEM

[Konrad Dybcio]

On 2/6/26 7:22 PM, Mukesh Ojha wrote:
> On Wed, Feb 04, 2026 at 01:39:43PM +0100, Konrad Dybcio wrote:
>> 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@xxxxxxxxxxxxxxxx>
>>>>> ---
>>>>> 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@xxxxxxxxxxxxxxxx>
>>>
>>>
>>> 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?
> 
> It is attached to Minidump collection storage type selection like USB or UFS/eMMC.
> When we change dload mode (in SCM driver) to mini and change this IMEM to UFS
> then the Minidump will be stored in UFS.
> 
> It has to be SCM driver which should host this but it does not need to
> be driver or device creation.

Then I think something along these lines should be good:

sram@f00bar {
	compatible = "qcom,xxx-imem"....

	minidump_config: minidump-config@baz {
		reg = <0xbaz 0x1234>;
	};
};


...

scm {
	compatible = ...

	sram = <&minidump_config>;
	// perhaps "sram-names" too? doesn't exist today but scm seems
	// too broad to rely on an index-based lookup that works for everyone
				  
};

Konrad