On 6/16/2025 10:48 AM, Kathiravan Thirumoorthy wrote:

Thanks Rob for the review comments!

On 6/10/2025 11:33 PM, Rob Herring wrote:

quoted

On Tue, Jun 10, 2025 at 07:15:19PM +0530, Kathiravan Thirumoorthy wrote:

quoted

Document the "sram" property for the watchdog device on Qualcomm
IPQ platforms. Use this property to extract the restart reason from
IMEM, which is updated by XBL. Populate the watchdog's bootstatus sysFS
entry with this information, when the system reboots due to a watchdog
timeout.

Describe this property for the IPQ5424 watchdog device and extend 
support
to other targets subsequently.

Signed-off-by: Kathiravan Thirumoorthy 
[off-list ref]
---
Changes in v5:
    - Rename the property 'qcom,imem' to 'sram'
Changes in v4:
    - New patch
---
  .../devicetree/bindings/watchdog/qcom-wdt.yaml       | 20 
++++++++++++++++++++
  1 file changed, 20 insertions(+)

diff --git 

a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml 
b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
index 
49e2b807db0bc9d3edfc93ec41ad0df0b74ed032..74a09c391fd8e2befeac07f254ea16d0ca362248 
100644

--- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml

@@ -81,6 +81,16 @@ properties:

      minItems: 1
      maxItems: 5
  +  sram:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description:
+      phandle to the IMEM syscon node that exposes the system 
restart reason
+    items:
+      - items:
+          - description: phandle of IMEM syscon
+          - description: offset of restart reason region
+          - description: value indicate that the watchdog timeout 
has occurred

A 'sram' property points to an SRAM region (see mmio-sram binding), not
a syscon and offset.

The 'value' should be a separate property or implied by the compatible.

Sorry for the delay. It was a long weekend here!

Let me start with the requirement (Please feel free to skip it). When 
the system goes for reboot, Xtensible Boot loader (XBL) find the cause 
and update the particular offset (in this case it is 0x7b0) in the 
IMEM region with the known values. On the next boot, if the system is 
rebooted due to  watchdog timeout, watchdog's bootstatus is updated 
accordingly, which this series tries to address it.

Based on the previous review comments / discussions [1], it is decided 
to go with the above approach, i.e., name the property to 'sram' and 
let it points to the syscon region (IMEM) along with the offset to 
read and what value to expect. So that we don't have to touch the 
driver if either of the offset or the value changes across the platforms.

Currently, IMEM region (which is a on-chip SRAM) in the most of the 
QCOM platforms are modeled as 'syscon' [2]. So I have followed the 
same approach here as well. Should I describe the IMEM region as 
"sram" (mmio-sram)  instead of the "syscon" (existing approach) and 
retrieve the offset and desired value from the compatible? or stick 
with existing approach and name the property to something else? Could 
you guide me here to proceed further?

[1] 
https://lore.kernel.org/linux-arm-msm/20250519-wdt_reset_reason-v4-3-d59d21275c75@oss.qualcomm.com/#t (local)

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/sram/qcom,imem.yaml

Konrad,

The bootloader team confirmed that the IMEM offset and restart reason 
value are fixed for the SoC's lifetime. Based on Rob’s suggestion, let’s 
pull these values from the device data using the compatible string. Let 
me know your thoughts.

Kathiravan T.

Thanks,

Kathiravan T.

quoted

Rob