[PATCH 0/4] firmware: qcom: scm: Add minidump SRAM destination support

[PATCH 0/4] firmware: qcom: scm: Add minidump SRAM destination support

[Mukesh Ojha]

On most Qualcomm SoCs where minidump is supported, a word in always-on
SRAM is shared between the kernel and boot firmware. Before DDR is
initialised on the warm reset following a crash, firmware reads this
word to decide if minidump is enabled and collect a minidump and where
to deliver it (USB upload to a host, or save to local storage).

This series wires that mechanism into the SCM driver:

  - The SRAM word location is described via a 'sram'/'sram-names'
    phandle pair on the SCM DT node, keeping it decoupled from the
    driver and extensible to future SoCs.

  - A 'minidump_dest' module parameter (default: usb) selects the
    destination.  Custom kernel_param_ops expose it as the human-
    readable strings "usb" or "storage".

  - Add the support for Kaanapali.

Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/lkml/b33938e9-bb5c-4743-866d-4cdccf808a02@oss.qualcomm.com/
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>



Mukesh Ojha (4):
  dt-bindings: firmware: qcom,scm: Add minidump SRAM property
  firmware: qcom: scm: use dev_err_probe() for dload address failure
  firmware: qcom: scm: Add minidump SRAM support
  arm64: dts: qcom: kaanapali: Add minidump SRAM config to SCM node

 .../bindings/firmware/qcom,scm.yaml           | 57 +++++++++++
 arch/arm64/boot/dts/qcom/kaanapali.dtsi       |  6 ++
 drivers/firmware/qcom/qcom_scm.c              | 98 ++++++++++++++++++-
 3 files changed, 160 insertions(+), 1 deletion(-)

-- 
2.53.0

[PATCH 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property

[Mukesh Ojha]

On most Qualcomm SoCs where minidump is supported, a word in always-on
SRAM is shared between the kernel and boot firmware. Before DDR is
initialised on the warm reset following a crash, firmware reads this
word to decide if minidump is enabled and collect a minidump and where
 to deliver it (USB upload to a host, or save to local storage).

Add 'sram' and 'sram-names' properties to the SCM binding to describe
a region in always-on SRAM where the minidump download destination
value could be written. Boot firmware reads it before DDR is initialised
on a warm reset to decide where to store the minidump either to host
PC or to on device storage.

Most of the Qualcomm SoC supporting minidump supports this, added the
kaanapali SoC for now.

Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 .../bindings/firmware/qcom,scm.yaml           | 57 +++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index 7918d31f58b4..6813081fd74a 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -127,6 +127,22 @@ properties:
           - description: offset of the download mode control register
     description: TCSR hardware block
 
+  sram:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description:
+      Phandle to a region in always-on SRAM used to store the download
+      mode value for boot firmware to read before DDR is initialised on
+      the next warm reset.
+    maxItems: 1
+
+  sram-names:
+    items:
+      - const: minidump
+
+dependencies:
+  sram: [ sram-names ]
+  sram-names: [ sram ]
+
 allOf:
   # Clocks
   - if:
@@ -229,6 +245,18 @@ allOf:
       properties:
         memory-region: false
 
+  - if:
+      not:
+        properties:
+          compatible:
+            contains:
+              enum:
+                - qcom,scm-kaanapali
+    then:
+      properties:
+        sram: false
+        sram-names: false
+
 required:
   - compatible
 
@@ -247,3 +275,32 @@ examples:
             clock-names = "core", "bus", "iface";
         };
     };
+
+  - |
+    /* kaanapali — minidump SRAM */
+    / {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        sram@14680000 {
+            compatible = "qcom,kaanapali-imem", "mmio-sram";
+            reg = <0x0 0x14680000 0x0 0x1000>;
+            ranges = <0x0 0x0 0x14680000 0x1000>;
+            no-memory-wc;
+            #address-cells = <1>;
+            #size-cells = <1>;
+
+            minidump_config: minidump-config@1c {
+                reg = <0x1c 0x4>;
+            };
+        };
+
+        firmware {
+            scm {
+                compatible = "qcom,scm-kaanapali", "qcom,scm";
+                sram = <&minidump_config>;
+                sram-names = "minidump";
+                #reset-cells = <1>;
+            };
+        };
+    };
-- 
2.53.0

Re: [PATCH 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property

[Rob Herring (Arm)]

On Thu, 07 May 2026 13:37:17 +0530, Mukesh Ojha wrote:
> On most Qualcomm SoCs where minidump is supported, a word in always-on
> SRAM is shared between the kernel and boot firmware. Before DDR is
> initialised on the warm reset following a crash, firmware reads this
> word to decide if minidump is enabled and collect a minidump and where
>  to deliver it (USB upload to a host, or save to local storage).
> 
> Add 'sram' and 'sram-names' properties to the SCM binding to describe
> a region in always-on SRAM where the minidump download destination
> value could be written. Boot firmware reads it before DDR is initialised
> on a warm reset to decide where to store the minidump either to host
> PC or to on device storage.
> 
> Most of the Qualcomm SoC supporting minidump supports this, added the
> kaanapali SoC for now.
> 
> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
>  .../bindings/firmware/qcom,scm.yaml           | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/qcom,scm.example.dtb: sram@14680000 (qcom,kaanapali-imem): 'minidump-config@1c' does not match any of the regexes: '^([a-z0-9]+-)*sram(-section)?@[a-f0-9]+$', '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/sram/sram.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260507080727.3227367-2-mukesh.ojha@oss.qualcomm.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property

[Konrad Dybcio]

On 5/7/26 10:07 AM, Mukesh Ojha wrote:
> On most Qualcomm SoCs where minidump is supported, a word in always-on
> SRAM is shared between the kernel and boot firmware. Before DDR is
> initialised on the warm reset following a crash, firmware reads this
> word to decide if minidump is enabled and collect a minidump and where
>  to deliver it (USB upload to a host, or save to local storage).
> 
> Add 'sram' and 'sram-names' properties to the SCM binding to describe
> a region in always-on SRAM where the minidump download destination
> value could be written. Boot firmware reads it before DDR is initialised
> on a warm reset to decide where to store the minidump either to host
> PC or to on device storage.
> 
> Most of the Qualcomm SoC supporting minidump supports this, added the
> kaanapali SoC for now.
> 
> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Thank you for the attribution, but I don't think it applies here - 
Suggested-by would be fitting if I said "hey Mukesh, could you please
do XYZ ABC [which you weren't planning on doing]", this is more of a
normal review feedback

Konrad

Re: [PATCH 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property

[Konrad Dybcio]

On 5/7/26 10:07 AM, Mukesh Ojha wrote:
> On most Qualcomm SoCs where minidump is supported, a word in always-on
> SRAM is shared between the kernel and boot firmware. Before DDR is
> initialised on the warm reset following a crash, firmware reads this
> word to decide if minidump is enabled and collect a minidump and where
>  to deliver it (USB upload to a host, or save to local storage).
> 
> Add 'sram' and 'sram-names' properties to the SCM binding to describe
> a region in always-on SRAM where the minidump download destination
> value could be written. Boot firmware reads it before DDR is initialised
> on a warm reset to decide where to store the minidump either to host
> PC or to on device storage.
> 
> Most of the Qualcomm SoC supporting minidump supports this, added the
> kaanapali SoC for now.
> 
> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
>  .../bindings/firmware/qcom,scm.yaml           | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> index 7918d31f58b4..6813081fd74a 100644
> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> @@ -127,6 +127,22 @@ properties:
>            - description: offset of the download mode control register
>      description: TCSR hardware block
>  
> +  sram:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description:
> +      Phandle to a region in always-on SRAM used to store the download
> +      mode value for boot firmware to read before DDR is initialised on
> +      the next warm reset.
> +    maxItems: 1
> +
> +  sram-names:
> +    items:
> +      - const: minidump
> +
> +dependencies:
> +  sram: [ sram-names ]
> +  sram-names: [ sram ]
> +
>  allOf:
>    # Clocks
>    - if:
> @@ -229,6 +245,18 @@ allOf:
>        properties:
>          memory-region: false
>  
> +  - if:
> +      not:
> +        properties:
> +          compatible:
> +            contains:
> +              enum:
> +                - qcom,scm-kaanapali

This list will grow super large - like mentioned in the commit message,
to list almost all platforms.. I don't know if it makes sense to limit
this. Krzysztof/Rob?

Konrad

Re: [PATCH 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property

[Rob Herring]

On Fri, May 8, 2026 at 5:50 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 5/7/26 10:07 AM, Mukesh Ojha wrote:
> > On most Qualcomm SoCs where minidump is supported, a word in always-on
> > SRAM is shared between the kernel and boot firmware. Before DDR is
> > initialised on the warm reset following a crash, firmware reads this
> > word to decide if minidump is enabled and collect a minidump and where
> >  to deliver it (USB upload to a host, or save to local storage).
> >
> > Add 'sram' and 'sram-names' properties to the SCM binding to describe
> > a region in always-on SRAM where the minidump download destination
> > value could be written. Boot firmware reads it before DDR is initialised
> > on a warm reset to decide where to store the minidump either to host
> > PC or to on device storage.
> >
> > Most of the Qualcomm SoC supporting minidump supports this, added the
> > kaanapali SoC for now.
> >
> > Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> >  .../bindings/firmware/qcom,scm.yaml           | 57 +++++++++++++++++++
> >  1 file changed, 57 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> > index 7918d31f58b4..6813081fd74a 100644
> > --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> > @@ -127,6 +127,22 @@ properties:
> >            - description: offset of the download mode control register
> >      description: TCSR hardware block
> >
> > +  sram:
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +    description:
> > +      Phandle to a region in always-on SRAM used to store the download
> > +      mode value for boot firmware to read before DDR is initialised on
> > +      the next warm reset.
> > +    maxItems: 1
> > +
> > +  sram-names:
> > +    items:
> > +      - const: minidump
> > +
> > +dependencies:
> > +  sram: [ sram-names ]
> > +  sram-names: [ sram ]
> > +
> >  allOf:
> >    # Clocks
> >    - if:
> > @@ -229,6 +245,18 @@ allOf:
> >        properties:
> >          memory-region: false
> >
> > +  - if:
> > +      not:
> > +        properties:
> > +          compatible:
> > +            contains:
> > +              enum:
> > +                - qcom,scm-kaanapali
>
> This list will grow super large - like mentioned in the commit message,
> to list almost all platforms.. I don't know if it makes sense to limit
> this. Krzysztof/Rob?

Probably not. If sram is not valid for a platform, you'd have to go
out of your way to first add it and to have any effect if you did.

Rob

Re: [PATCH 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property

[Rob Herring]

On Thu, May 7, 2026 at 3:07 AM Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> wrote:
>
> On most Qualcomm SoCs where minidump is supported, a word in always-on
> SRAM is shared between the kernel and boot firmware. Before DDR is
> initialised on the warm reset following a crash, firmware reads this
> word to decide if minidump is enabled and collect a minidump and where
>  to deliver it (USB upload to a host, or save to local storage).
>
> Add 'sram' and 'sram-names' properties to the SCM binding to describe
> a region in always-on SRAM where the minidump download destination
> value could be written. Boot firmware reads it before DDR is initialised
> on a warm reset to decide where to store the minidump either to host
> PC or to on device storage.
>
> Most of the Qualcomm SoC supporting minidump supports this, added the
> kaanapali SoC for now.
>
> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
>  .../bindings/firmware/qcom,scm.yaml           | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> index 7918d31f58b4..6813081fd74a 100644
> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> @@ -127,6 +127,22 @@ properties:
>            - description: offset of the download mode control register
>      description: TCSR hardware block
>
> +  sram:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array

Drop. This is a common property though we need to create a common definition.

> +    description:
> +      Phandle to a region in always-on SRAM used to store the download
> +      mode value for boot firmware to read before DDR is initialised on
> +      the next warm reset.
> +    maxItems: 1
> +
> +  sram-names:
> +    items:
> +      - const: minidump

You don't need -names with 1 entry and sram-names is not a common property.

> +
> +dependencies:
> +  sram: [ sram-names ]
> +  sram-names: [ sram ]
> +
>  allOf:
>    # Clocks
>    - if:
> @@ -229,6 +245,18 @@ allOf:
>        properties:
>          memory-region: false
>
> +  - if:
> +      not:
> +        properties:
> +          compatible:
> +            contains:
> +              enum:
> +                - qcom,scm-kaanapali
> +    then:
> +      properties:
> +        sram: false
> +        sram-names: false
> +
>  required:
>    - compatible
>
> @@ -247,3 +275,32 @@ examples:
>              clock-names = "core", "bus", "iface";
>          };
>      };
> +
> +  - |
> +    /* kaanapali — minidump SRAM */
> +    / {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        sram@14680000 {
> +            compatible = "qcom,kaanapali-imem", "mmio-sram";
> +            reg = <0x0 0x14680000 0x0 0x1000>;
> +            ranges = <0x0 0x0 0x14680000 0x1000>;
> +            no-memory-wc;
> +            #address-cells = <1>;
> +            #size-cells = <1>;
> +
> +            minidump_config: minidump-config@1c {
> +                reg = <0x1c 0x4>;
> +            };
> +        };

You don't need providers in examples. Really, don't need a whole other
example for 1 added property.

> +
> +        firmware {
> +            scm {
> +                compatible = "qcom,scm-kaanapali", "qcom,scm";
> +                sram = <&minidump_config>;
> +                sram-names = "minidump";
> +                #reset-cells = <1>;
> +            };
> +        };
> +    };
> --
> 2.53.0
>

[PATCH 2/4] firmware: qcom: scm: use dev_err_probe() for dload address failure

[Mukesh Ojha]

Replace the bare `return ret` after qcom_scm_find_dload_address() with
dev_err_probe() to produce a consistent, deferred-probe-aware error
message when the download-mode address cannot be resolved.

Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index d9ee180388aa..f65b132004a5 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2762,7 +2762,8 @@ static int qcom_scm_probe(struct platform_device *pdev)
 	scm->dev = &pdev->dev;
 	ret = qcom_scm_find_dload_address(&pdev->dev, &scm->dload_mode_addr);
 	if (ret < 0)
-		return ret;
+		return dev_err_probe(&pdev->dev, ret,
+				     "Failed to find download mode address\n");
 
 	mutex_init(&scm->scm_bw_lock);
 
-- 
2.53.0

Re: [PATCH 2/4] firmware: qcom: scm: use dev_err_probe() for dload address failure

[Dmitry Baryshkov]

On Thu, May 07, 2026 at 01:37:18PM +0530, Mukesh Ojha wrote:
> Replace the bare `return ret` after qcom_scm_find_dload_address() with
> dev_err_probe() to produce a consistent, deferred-probe-aware error
> message when the download-mode address cannot be resolved.
> 
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index d9ee180388aa..f65b132004a5 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2762,7 +2762,8 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  	scm->dev = &pdev->dev;
>  	ret = qcom_scm_find_dload_address(&pdev->dev, &scm->dload_mode_addr);
>  	if (ret < 0)
> -		return ret;
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "Failed to find download mode address\n");

Maybe 'get' rather than 'find.

Anyway,


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



>  
>  	mutex_init(&scm->scm_bw_lock);
>  
> -- 
> 2.53.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH 2/4] firmware: qcom: scm: use dev_err_probe() for dload address failure

[Bjorn Andersson]

On Thu, May 07, 2026 at 01:37:18PM +0530, Mukesh Ojha wrote:
> Replace the bare `return ret` after qcom_scm_find_dload_address() with

Describe a problem, not an action.

Why is this patch part of this series? I don't see how it relate to
"minidump SRAM destination support".


Change looks reasonable.

Regards,
Bjorn

> dev_err_probe() to produce a consistent, deferred-probe-aware error
> message when the download-mode address cannot be resolved.
> 
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index d9ee180388aa..f65b132004a5 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2762,7 +2762,8 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  	scm->dev = &pdev->dev;
>  	ret = qcom_scm_find_dload_address(&pdev->dev, &scm->dload_mode_addr);
>  	if (ret < 0)
> -		return ret;
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "Failed to find download mode address\n");
>  
>  	mutex_init(&scm->scm_bw_lock);
>  
> -- 
> 2.53.0
> 

Re: [PATCH 2/4] firmware: qcom: scm: use dev_err_probe() for dload address failure

[Konrad Dybcio]

On 5/7/26 10:07 AM, Mukesh Ojha wrote:
> Replace the bare `return ret` after qcom_scm_find_dload_address() with
> dev_err_probe() to produce a consistent, deferred-probe-aware error
> message when the download-mode address cannot be resolved.
> 
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH 3/4] firmware: qcom: scm: Add minidump SRAM support

[Mukesh Ojha]

On most Qualcomm SoCs where minidump is supported, a word in always-on
SRAM is shared between the kernel and boot firmware. Before DDR is
initialised on the warm reset following a crash, firmware reads this
word to decide if minidump is enabled and collect a minidump and where
to deliver it (USB upload to a host, or save to local storage).

The SRAM region is described by a 'sram'/'sram-names' phandle pair on
the SCM DT node. If the property is absent the feature is silently
disabled, keeping existing SoCs unaffected.

Expose a 'minidump_dest' module parameter (default: usb) so the user can
select the destination. Only the string names "usb" or "storage" are
accepted; an invalid value is rejected with -EINVAL. Changing the
destination while minidump mode is already active updates SRAM immediately.

Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index f65b132004a5..b57f8cce7a8c 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -57,6 +57,7 @@ struct qcom_scm {
 	int scm_vote_count;
 
 	u64 dload_mode_addr;
+	void __iomem *minidump_sram;
 
 	struct qcom_tzmem_pool *mempool;
 	unsigned int wq_cnt;
@@ -141,6 +142,18 @@ static const u8 qcom_scm_cpu_warm_bits[QCOM_SCM_BOOT_MAX_CPUS] = {
 #define QCOM_DLOAD_MINIDUMP	2
 #define QCOM_DLOAD_BOTHDUMP	3
 
+/* Minidump destination values written to always-on SRAM for boot firmware */
+#define QCOM_MINIDUMP_DEST_USB		0x0
+#define QCOM_MINIDUMP_DEST_STORAGE	0x2
+
+static u32 minidump_dest = QCOM_MINIDUMP_DEST_USB;
+
+static const char * const minidump_dest_name[] = { "usb", "storage" };
+static const u32 minidump_dest_val[] = {
+	QCOM_MINIDUMP_DEST_USB,
+	QCOM_MINIDUMP_DEST_STORAGE,
+};
+
 #define QCOM_SCM_DEFAULT_WAITQ_COUNT 1
 
 static const char * const qcom_scm_convention_names[] = {
@@ -568,6 +581,17 @@ static void qcom_scm_set_download_mode(u32 dload_mode)
 
 	if (ret)
 		dev_err(__scm->dev, "failed to set download mode: %d\n", ret);
+
+	/*
+	 * Mirror the destination into the always-on SRAM so boot firmware
+	 * can read it before DDR is initialised on the next warm reset.
+	 * Only written when minidump is active; skip if SRAM already holds
+	 * the requested destination to avoid unnecessary writes.
+	 */
+	if (__scm->minidump_sram && (dload_mode & QCOM_DLOAD_MINIDUMP)) {
+		if (readl_relaxed(__scm->minidump_sram) != minidump_dest)
+			writel_relaxed(minidump_dest, __scm->minidump_sram);
+	}
 }
 
 /**
@@ -2055,6 +2079,37 @@ int qcom_scm_gpu_init_regs(u32 gpu_req)
 }
 EXPORT_SYMBOL_GPL(qcom_scm_gpu_init_regs);
 
+static int qcom_scm_map_minidump_sram(struct device *dev, void __iomem **out)
+{
+	struct device_node *np = dev->of_node;
+	struct device_node *sram_np;
+	struct resource res;
+	int ret;
+
+	if (of_property_match_string(np, "sram-names", "minidump") < 0)
+		return 0;
+
+	sram_np = of_parse_phandle(np, "sram", 0);
+	if (!sram_np)
+		return -EINVAL;
+
+	ret = of_address_to_resource(sram_np, 0, &res);
+	of_node_put(sram_np);
+	if (ret)
+		return ret;
+
+	if (resource_size(&res) < sizeof(u32)) {
+		dev_err(dev, "minidump SRAM region too small\n");
+		return -EINVAL;
+	}
+
+	*out = devm_ioremap(dev, res.start, resource_size(&res));
+	if (!*out)
+		return -ENOMEM;
+
+	return 0;
+}
+
 static int qcom_scm_find_dload_address(struct device *dev, u64 *addr)
 {
 	struct device_node *tcsr;
@@ -2748,6 +2803,41 @@ static const struct kernel_param_ops download_mode_param_ops = {
 module_param_cb(download_mode, &download_mode_param_ops, NULL, 0644);
 MODULE_PARM_DESC(download_mode, "download mode: off/0/N for no dump mode, full/on/1/Y for full dump mode, mini for minidump mode and full,mini for both full and minidump mode together are acceptable values");
 
+static int get_minidump_dest(char *buffer, const struct kernel_param *kp)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(minidump_dest_val); i++)
+		if (minidump_dest == minidump_dest_val[i])
+			return sysfs_emit(buffer, "%s\n", minidump_dest_name[i]);
+
+	return sysfs_emit(buffer, "unknown\n");
+}
+
+static int set_minidump_dest(const char *val, const struct kernel_param *kp)
+{
+	int i;
+
+	i = sysfs_match_string(minidump_dest_name, val);
+	if (i < 0)
+		return -EINVAL;
+
+	minidump_dest = minidump_dest_val[i];
+	if (__scm && __scm->minidump_sram && (download_mode & QCOM_DLOAD_MINIDUMP) &&
+	    readl_relaxed(__scm->minidump_sram) != minidump_dest)
+		writel_relaxed(minidump_dest, __scm->minidump_sram);
+
+	return 0;
+}
+
+static const struct kernel_param_ops minidump_dest_param_ops = {
+	.get = get_minidump_dest,
+	.set = set_minidump_dest,
+};
+
+module_param_cb(minidump_dest, &minidump_dest_param_ops, NULL, 0644);
+MODULE_PARM_DESC(minidump_dest, "Minidump SRAM destination: usb (default) or storage");
+
 static int qcom_scm_probe(struct platform_device *pdev)
 {
 	struct qcom_tzmem_pool_config pool_config;
@@ -2765,6 +2855,11 @@ static int qcom_scm_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, ret,
 				     "Failed to find download mode address\n");
 
+	ret = qcom_scm_map_minidump_sram(&pdev->dev, &scm->minidump_sram);
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret,
+				     "Failed to map minidump SRAM\n");
+
 	mutex_init(&scm->scm_bw_lock);
 
 	scm->path = devm_of_icc_get(&pdev->dev, NULL);
-- 
2.53.0

Re: [PATCH 3/4] firmware: qcom: scm: Add minidump SRAM support

[Dmitry Baryshkov]

On Thu, May 07, 2026 at 01:37:19PM +0530, Mukesh Ojha wrote:
> On most Qualcomm SoCs where minidump is supported, a word in always-on
> SRAM is shared between the kernel and boot firmware. Before DDR is
> initialised on the warm reset following a crash, firmware reads this
> word to decide if minidump is enabled and collect a minidump and where
> to deliver it (USB upload to a host, or save to local storage).
> 
> The SRAM region is described by a 'sram'/'sram-names' phandle pair on
> the SCM DT node. If the property is absent the feature is silently
> disabled, keeping existing SoCs unaffected.
> 
> Expose a 'minidump_dest' module parameter (default: usb) so the user can
> select the destination. Only the string names "usb" or "storage" are
> accepted; an invalid value is rejected with -EINVAL. Changing the
> destination while minidump mode is already active updates SRAM immediately.
> 
> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 95 ++++++++++++++++++++++++++++++++
>  1 file changed, 95 insertions(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index f65b132004a5..b57f8cce7a8c 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -57,6 +57,7 @@ struct qcom_scm {
>  	int scm_vote_count;
>  
>  	u64 dload_mode_addr;
> +	void __iomem *minidump_sram;
>  
>  	struct qcom_tzmem_pool *mempool;
>  	unsigned int wq_cnt;
> @@ -141,6 +142,18 @@ static const u8 qcom_scm_cpu_warm_bits[QCOM_SCM_BOOT_MAX_CPUS] = {
>  #define QCOM_DLOAD_MINIDUMP	2
>  #define QCOM_DLOAD_BOTHDUMP	3
>  
> +/* Minidump destination values written to always-on SRAM for boot firmware */
> +#define QCOM_MINIDUMP_DEST_USB		0x0
> +#define QCOM_MINIDUMP_DEST_STORAGE	0x2

This makes one wonder, what is 0x01

> +
> +static u32 minidump_dest = QCOM_MINIDUMP_DEST_USB;
> +
> +static const char * const minidump_dest_name[] = { "usb", "storage" };
> +static const u32 minidump_dest_val[] = {
> +	QCOM_MINIDUMP_DEST_USB,
> +	QCOM_MINIDUMP_DEST_STORAGE,
> +};
> +
>  #define QCOM_SCM_DEFAULT_WAITQ_COUNT 1
>  
>  static const char * const qcom_scm_convention_names[] = {
> @@ -568,6 +581,17 @@ static void qcom_scm_set_download_mode(u32 dload_mode)
>  
>  	if (ret)
>  		dev_err(__scm->dev, "failed to set download mode: %d\n", ret);
> +
> +	/*
> +	 * Mirror the destination into the always-on SRAM so boot firmware
> +	 * can read it before DDR is initialised on the next warm reset.
> +	 * Only written when minidump is active; skip if SRAM already holds
> +	 * the requested destination to avoid unnecessary writes.

And writes are bad, because?

> +	 */
> +	if (__scm->minidump_sram && (dload_mode & QCOM_DLOAD_MINIDUMP)) {
> +		if (readl_relaxed(__scm->minidump_sram) != minidump_dest)
> +			writel_relaxed(minidump_dest, __scm->minidump_sram);
> +	}
>  }
>  
>  /**
> @@ -2055,6 +2079,37 @@ int qcom_scm_gpu_init_regs(u32 gpu_req)
>  }
>  EXPORT_SYMBOL_GPL(qcom_scm_gpu_init_regs);
>  
> +static int qcom_scm_map_minidump_sram(struct device *dev, void __iomem **out)
> +{
> +	struct device_node *np = dev->of_node;
> +	struct device_node *sram_np;
> +	struct resource res;
> +	int ret;
> +
> +	if (of_property_match_string(np, "sram-names", "minidump") < 0)
> +		return 0;

Do you actually need sram-names? Just to verify that it has one string?

> +
> +	sram_np = of_parse_phandle(np, "sram", 0);
> +	if (!sram_np)
> +		return -EINVAL;
> +
> +	ret = of_address_to_resource(sram_np, 0, &res);
> +	of_node_put(sram_np);
> +	if (ret)
> +		return ret;
> +
> +	if (resource_size(&res) < sizeof(u32)) {
> +		dev_err(dev, "minidump SRAM region too small\n");
> +		return -EINVAL;
> +	}
> +
> +	*out = devm_ioremap(dev, res.start, resource_size(&res));
> +	if (!*out)
> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +
>  static int qcom_scm_find_dload_address(struct device *dev, u64 *addr)
>  {
>  	struct device_node *tcsr;
> @@ -2748,6 +2803,41 @@ static const struct kernel_param_ops download_mode_param_ops = {
>  module_param_cb(download_mode, &download_mode_param_ops, NULL, 0644);
>  MODULE_PARM_DESC(download_mode, "download mode: off/0/N for no dump mode, full/on/1/Y for full dump mode, mini for minidump mode and full,mini for both full and minidump mode together are acceptable values");
>  
> +static int get_minidump_dest(char *buffer, const struct kernel_param *kp)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(minidump_dest_val); i++)
> +		if (minidump_dest == minidump_dest_val[i])
> +			return sysfs_emit(buffer, "%s\n", minidump_dest_name[i]);
> +
> +	return sysfs_emit(buffer, "unknown\n");
> +}
> +
> +static int set_minidump_dest(const char *val, const struct kernel_param *kp)
> +{
> +	int i;
> +
> +	i = sysfs_match_string(minidump_dest_name, val);
> +	if (i < 0)
> +		return -EINVAL;
> +
> +	minidump_dest = minidump_dest_val[i];
> +	if (__scm && __scm->minidump_sram && (download_mode & QCOM_DLOAD_MINIDUMP) &&
> +	    readl_relaxed(__scm->minidump_sram) != minidump_dest)
> +		writel_relaxed(minidump_dest, __scm->minidump_sram);
> +
> +	return 0;
> +}
> +
> +static const struct kernel_param_ops minidump_dest_param_ops = {
> +	.get = get_minidump_dest,
> +	.set = set_minidump_dest,
> +};
> +
> +module_param_cb(minidump_dest, &minidump_dest_param_ops, NULL, 0644);
> +MODULE_PARM_DESC(minidump_dest, "Minidump SRAM destination: usb (default) or storage");
> +
>  static int qcom_scm_probe(struct platform_device *pdev)
>  {
>  	struct qcom_tzmem_pool_config pool_config;
> @@ -2765,6 +2855,11 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  		return dev_err_probe(&pdev->dev, ret,
>  				     "Failed to find download mode address\n");
>  
> +	ret = qcom_scm_map_minidump_sram(&pdev->dev, &scm->minidump_sram);
> +	if (ret < 0)
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "Failed to map minidump SRAM\n");
> +
>  	mutex_init(&scm->scm_bw_lock);
>  
>  	scm->path = devm_of_icc_get(&pdev->dev, NULL);
> -- 
> 2.53.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] firmware: qcom: scm: Add minidump SRAM support

[Mukesh Ojha]

On Thu, May 07, 2026 at 04:50:31PM +0300, Dmitry Baryshkov wrote:
> On Thu, May 07, 2026 at 01:37:19PM +0530, Mukesh Ojha wrote:
> > On most Qualcomm SoCs where minidump is supported, a word in always-on
> > SRAM is shared between the kernel and boot firmware. Before DDR is
> > initialised on the warm reset following a crash, firmware reads this
> > word to decide if minidump is enabled and collect a minidump and where
> > to deliver it (USB upload to a host, or save to local storage).
> > 
> > The SRAM region is described by a 'sram'/'sram-names' phandle pair on
> > the SCM DT node. If the property is absent the feature is silently
> > disabled, keeping existing SoCs unaffected.
> > 
> > Expose a 'minidump_dest' module parameter (default: usb) so the user can
> > select the destination. Only the string names "usb" or "storage" are
> > accepted; an invalid value is rejected with -EINVAL. Changing the
> > destination while minidump mode is already active updates SRAM immediately.
> > 
> > Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> >  drivers/firmware/qcom/qcom_scm.c | 95 ++++++++++++++++++++++++++++++++
> >  1 file changed, 95 insertions(+)
> > 
> > diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> > index f65b132004a5..b57f8cce7a8c 100644
> > --- a/drivers/firmware/qcom/qcom_scm.c
> > +++ b/drivers/firmware/qcom/qcom_scm.c
> > @@ -57,6 +57,7 @@ struct qcom_scm {
> >  	int scm_vote_count;
> >  
> >  	u64 dload_mode_addr;
> > +	void __iomem *minidump_sram;
> >  
> >  	struct qcom_tzmem_pool *mempool;
> >  	unsigned int wq_cnt;
> > @@ -141,6 +142,18 @@ static const u8 qcom_scm_cpu_warm_bits[QCOM_SCM_BOOT_MAX_CPUS] = {
> >  #define QCOM_DLOAD_MINIDUMP	2
> >  #define QCOM_DLOAD_BOTHDUMP	3
> >  
> > +/* Minidump destination values written to always-on SRAM for boot firmware */
> > +#define QCOM_MINIDUMP_DEST_USB		0x0
> > +#define QCOM_MINIDUMP_DEST_STORAGE	0x2
> 
> This makes one wonder, what is 0x01

0x01 was for some legacy SoC and don't know what it is used for as I can
not find any reference 4.4 kernel onwards .,

> 
> > +
> > +static u32 minidump_dest = QCOM_MINIDUMP_DEST_USB;
> > +
> > +static const char * const minidump_dest_name[] = { "usb", "storage" };
> > +static const u32 minidump_dest_val[] = {
> > +	QCOM_MINIDUMP_DEST_USB,
> > +	QCOM_MINIDUMP_DEST_STORAGE,
> > +};
> > +
> >  #define QCOM_SCM_DEFAULT_WAITQ_COUNT 1
> >  
> >  static const char * const qcom_scm_convention_names[] = {
> > @@ -568,6 +581,17 @@ static void qcom_scm_set_download_mode(u32 dload_mode)
> >  
> >  	if (ret)
> >  		dev_err(__scm->dev, "failed to set download mode: %d\n", ret);
> > +
> > +	/*
> > +	 * Mirror the destination into the always-on SRAM so boot firmware
> > +	 * can read it before DDR is initialised on the next warm reset.
> > +	 * Only written when minidump is active; skip if SRAM already holds
> > +	 * the requested destination to avoid unnecessary writes.
> 
> And writes are bad, because?

I did not get what you mean here, nothing bad will happen even if we write.,
or you are asking why can't I write unconditionally ? we can do so..

> 
> > +	 */
> > +	if (__scm->minidump_sram && (dload_mode & QCOM_DLOAD_MINIDUMP)) {
> > +		if (readl_relaxed(__scm->minidump_sram) != minidump_dest)
> > +			writel_relaxed(minidump_dest, __scm->minidump_sram);
> > +	}
> >  }
> >  
> >  /**
> > @@ -2055,6 +2079,37 @@ int qcom_scm_gpu_init_regs(u32 gpu_req)
> >  }
> >  EXPORT_SYMBOL_GPL(qcom_scm_gpu_init_regs);
> >  
> > +static int qcom_scm_map_minidump_sram(struct device *dev, void __iomem **out)
> > +{
> > +	struct device_node *np = dev->of_node;
> > +	struct device_node *sram_np;
> > +	struct resource res;
> > +	int ret;
> > +
> > +	if (of_property_match_string(np, "sram-names", "minidump") < 0)
> > +		return 0;
> 
> Do you actually need sram-names? Just to verify that it has one string?

I kept the suggestion given here https://lore.kernel.org/lkml/b33938e9-bb5c-4743-866d-4cdccf808a02@oss.qualcomm.com/

Ideally, not needed but I agree sram too generic name for a property.
Any suggestion ?

> > +
> > +	sram_np = of_parse_phandle(np, "sram", 0);
> > +	if (!sram_np)
> > +		return -EINVAL;
> > +
> > +	ret = of_address_to_resource(sram_np, 0, &res);
> > +	of_node_put(sram_np);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (resource_size(&res) < sizeof(u32)) {
> > +		dev_err(dev, "minidump SRAM region too small\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	*out = devm_ioremap(dev, res.start, resource_size(&res));
> > +	if (!*out)
> > +		return -ENOMEM;
> > +
> > +	return 0;
> > +}
> > +
> >  static int qcom_scm_find_dload_address(struct device *dev, u64 *addr)
> >  {
> >  	struct device_node *tcsr;
> > @@ -2748,6 +2803,41 @@ static const struct kernel_param_ops download_mode_param_ops = {
> >  module_param_cb(download_mode, &download_mode_param_ops, NULL, 0644);
> >  MODULE_PARM_DESC(download_mode, "download mode: off/0/N for no dump mode, full/on/1/Y for full dump mode, mini for minidump mode and full,mini for both full and minidump mode together are acceptable values");
> >  
> > +static int get_minidump_dest(char *buffer, const struct kernel_param *kp)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(minidump_dest_val); i++)
> > +		if (minidump_dest == minidump_dest_val[i])
> > +			return sysfs_emit(buffer, "%s\n", minidump_dest_name[i]);
> > +
> > +	return sysfs_emit(buffer, "unknown\n");
> > +}
> > +
> > +static int set_minidump_dest(const char *val, const struct kernel_param *kp)
> > +{
> > +	int i;
> > +
> > +	i = sysfs_match_string(minidump_dest_name, val);
> > +	if (i < 0)
> > +		return -EINVAL;
> > +
> > +	minidump_dest = minidump_dest_val[i];
> > +	if (__scm && __scm->minidump_sram && (download_mode & QCOM_DLOAD_MINIDUMP) &&
> > +	    readl_relaxed(__scm->minidump_sram) != minidump_dest)
> > +		writel_relaxed(minidump_dest, __scm->minidump_sram);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct kernel_param_ops minidump_dest_param_ops = {
> > +	.get = get_minidump_dest,
> > +	.set = set_minidump_dest,
> > +};
> > +
> > +module_param_cb(minidump_dest, &minidump_dest_param_ops, NULL, 0644);
> > +MODULE_PARM_DESC(minidump_dest, "Minidump SRAM destination: usb (default) or storage");
> > +
> >  static int qcom_scm_probe(struct platform_device *pdev)
> >  {
> >  	struct qcom_tzmem_pool_config pool_config;
> > @@ -2765,6 +2855,11 @@ static int qcom_scm_probe(struct platform_device *pdev)
> >  		return dev_err_probe(&pdev->dev, ret,
> >  				     "Failed to find download mode address\n");
> >  
> > +	ret = qcom_scm_map_minidump_sram(&pdev->dev, &scm->minidump_sram);
> > +	if (ret < 0)
> > +		return dev_err_probe(&pdev->dev, ret,
> > +				     "Failed to map minidump SRAM\n");
> > +
> >  	mutex_init(&scm->scm_bw_lock);
> >  
> >  	scm->path = devm_of_icc_get(&pdev->dev, NULL);
> > -- 
> > 2.53.0
> > 
> 
> -- 
> With best wishes
> Dmitry

-- 
-Mukesh Ojha

Re: [PATCH 3/4] firmware: qcom: scm: Add minidump SRAM support

[Konrad Dybcio]

On 5/7/26 3:50 PM, Dmitry Baryshkov wrote:
> On Thu, May 07, 2026 at 01:37:19PM +0530, Mukesh Ojha wrote:
>> On most Qualcomm SoCs where minidump is supported, a word in always-on
>> SRAM is shared between the kernel and boot firmware. Before DDR is
>> initialised on the warm reset following a crash, firmware reads this
>> word to decide if minidump is enabled and collect a minidump and where
>> to deliver it (USB upload to a host, or save to local storage).
>>
>> The SRAM region is described by a 'sram'/'sram-names' phandle pair on
>> the SCM DT node. If the property is absent the feature is silently
>> disabled, keeping existing SoCs unaffected.
>>
>> Expose a 'minidump_dest' module parameter (default: usb) so the user can
>> select the destination. Only the string names "usb" or "storage" are
>> accepted; an invalid value is rejected with -EINVAL. Changing the
>> destination while minidump mode is already active updates SRAM immediately.
>>
>> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>> ---


>> +	if (of_property_match_string(np, "sram-names", "minidump") < 0)
>> +		return 0;
> 
> Do you actually need sram-names? Just to verify that it has one string?

I requested that, because SCM is a very generic node and index-based
lookups would age like fine milk

Konrad

[PATCH 4/4] arm64: dts: qcom: kaanapali: Add minidump SRAM config to SCM node

[Mukesh Ojha]

Wire up the minidump destination word in the kaanapali always-on SRAM
to the SCM node. It is used for destination place for collection of
minidump whether it is via USB to the host PC or to on device
storage.

Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..06d6da6877f9 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -224,6 +224,8 @@ scm: scm {
 			qcom,dload-mode = <&tcsr 0x19000>;
 			interconnects = <&aggre_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
 					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+			sram = <&minidump_config>;
+			sram-names = "minidump";
 		};
 
 		scmi: scmi {
@@ -5294,6 +5296,10 @@ sram@14680000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-config@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-sram@94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x94c 0xc8>;
-- 
2.53.0

Re: [PATCH 0/4] firmware: qcom: scm: Add minidump SRAM destination support

[Mukesh Ojha]

On Thu, May 07, 2026 at 01:37:16PM +0530, Mukesh Ojha wrote:
> On most Qualcomm SoCs where minidump is supported, a word in always-on
> SRAM is shared between the kernel and boot firmware. Before DDR is
> initialised on the warm reset following a crash, firmware reads this
> word to decide if minidump is enabled and collect a minidump and where
> to deliver it (USB upload to a host, or save to local storage).
> 
> This series wires that mechanism into the SCM driver:
> 
>   - The SRAM word location is described via a 'sram'/'sram-names'
>     phandle pair on the SCM DT node, keeping it decoupled from the
>     driver and extensible to future SoCs.
> 
>   - A 'minidump_dest' module parameter (default: usb) selects the
>     destination.  Custom kernel_param_ops expose it as the human-
>     readable strings "usb" or "storage".
> 
>   - Add the support for Kaanapali.
> 
> Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Link: https://lore.kernel.org/lkml/b33938e9-bb5c-4743-866d-4cdccf808a02@oss.qualcomm.com/
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>

I meant this to be RFC., would fix the minor schema error if this
suggestion received well.


-Mukesh

-- 
-Mukesh Ojha