* Re: [PATCH v4 04/19] firmware: qcom: scm: use dev_err_probe() for dload address failure
From: sashiko-bot @ 2026-06-24 19:22 UTC (permalink / raw)
To: Mukesh Ojha; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260624190830.3131112-5-mukesh.ojha@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The global `qcom_tzmem_dev` pointer is set during `qcom_tzmem_enable()` but is never cleared on probe failure, causing subsequent probe retries to permanently fail with `-EBUSY`.
- [High] The probe function calls `of_reserved_mem_device_init()` but does not call `of_reserved_mem_device_release()` on subsequent error paths, leading to permanent probe failure or resource leaks upon probe retry.
--
commit 6dc15526252b78a9c217f06ed35ed4966a794450
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
firmware: qcom: scm: use dev_err_probe() for dload address failure
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.
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index c8a84836887f0..6cd4d9468456f 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2750,7 +2750,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 get download mode address\n");
>
> mutex_init(&scm->scm_bw_lock);
[Severity: High]
This is a pre-existing issue, but does qcom_scm_probe() properly release
resources on later probe failures?
Later in qcom_scm_probe(), of_reserved_mem_device_init() is called to setup
reserved memory:
drivers/firmware/qcom/qcom_scm.c:qcom_scm_probe() {
...
ret = of_reserved_mem_device_init(scm->dev);
if (ret && ret != -ENODEV)
return dev_err_probe(scm->dev, ret,
"Failed to setup the reserved memory region for TZ mem\n");
...
}
However, subsequent error paths, such as platform_get_irq_optional() returning
-EPROBE_DEFER, exit directly without calling of_reserved_mem_device_release().
If the probe is deferred, will this cause the next probe attempt to fail with
-EBUSY, or leak memory by duplicating the rmem_assigned_device list entry on
every retry?
[Severity: High]
This is a pre-existing issue, but does qcom_tzmem_enable() cause a permanent
probe failure if qcom_scm_probe() defers later in the function?
qcom_tzmem_enable() sets a static qcom_tzmem_dev pointer in qcom_tzmem.c:
drivers/firmware/qcom/qcom_tzmem.c:qcom_tzmem_enable() {
if (qcom_tzmem_dev)
return -EBUSY;
qcom_tzmem_dev = dev;
return qcom_tzmem_init();
}
Since qcom_scm_probe() does not clear this pointer if it defers after this
call, will subsequent probe retries permanently fail with -EBUSY when
qcom_tzmem_enable() checks the still-set pointer?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com?part=4
^ permalink raw reply
* Re: [PATCH v4 01/19] dt-bindings: firmware: qcom,scm: Add minidump SRAM property
From: sashiko-bot @ 2026-06-24 19:19 UTC (permalink / raw)
To: Mukesh Ojha; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260624190830.3131112-2-mukesh.ojha@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing property type reference (`$ref`) for the `sram` property in the dt-binding schema.
--
commit 6acd1cecaeb951d30398f9208dd4e87b7cfd156e
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
dt-bindings: firmware: qcom,scm: Add minidump SRAM property
This commit adds a new 'sram' property to the Qualcomm SCM dt-binding. The
property is intended to contain a phandle to a region in always-on SRAM used
for minidump download destination configuration. This allows the OS to share
information with the boot firmware across warm resets.
> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> index 7918d31f58b4a..82c661db0b616 100644
> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> @@ -127,6 +127,13 @@ properties:
> - description: offset of the download mode control register
> description: TCSR hardware block
>
> + sram:
> + 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
[Severity: Low]
Does this property need an explicit type reference, such as
$ref: /schemas/types.yaml#/definitions/phandle?
Without a type definition, the dt-schema validator might infer the property
as an untyped array based on the presence of maxItems: 1. Could this allow
malformed device trees to pass validation silently since it won't enforce
that the provided value is actually a valid phandle?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com?part=1
^ permalink raw reply
* [PATCH v4 19/19] arm64: dts: qcom: sdm845: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 4ae8627d6dbc..2179988dbaaf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -363,6 +363,7 @@ cluster_sleep_0: cluster-sleep-0 {
firmware {
scm {
compatible = "qcom,scm-sdm845", "qcom,scm";
+ sram = <&minidump_config>;
};
};
@@ -5192,6 +5193,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x40000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@3d000 {
reg = <0x3d000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 18/19] arm64: dts: qcom: qcs615: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index fb1bbc51bb8a..a358d5441fa9 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -473,6 +473,7 @@ firmware {
scm {
compatible = "qcom,scm-qcs615", "qcom,scm";
qcom,dload-mode = <&tcsr 0x13000>;
+ sram = <&minidump_config>;
};
};
@@ -4654,6 +4655,10 @@ sram@14680000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@2a94c {
compatible = "qcom,pil-reloc-info";
reg = <0x2a94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 17/19] arm64: dts: qcom: sm6375: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm6375.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6375.dtsi b/arch/arm64/boot/dts/qcom/sm6375.dtsi
index ccf572bb1549..71a228597093 100644
--- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
@@ -307,6 +307,7 @@ scm {
compatible = "qcom,scm-sm6375", "qcom,scm";
clocks = <&rpmcc RPM_SMD_CE1_CLK>;
clock-names = "core";
+ sram = <&minidump_config>;
#reset-cells = <1>;
};
};
@@ -1645,6 +1646,10 @@ sram@c125000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@94c {
compatible = "qcom,pil-reloc-info";
reg = <0x94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 16/19] arm64: dts: qcom: sm6350: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index d6adf68563cb..06892ba22875 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -363,6 +363,7 @@ big_cpu_sleep_1: cpu-sleep-1-1 {
firmware {
scm: scm {
compatible = "qcom,scm-sm6350", "qcom,scm";
+ sram = <&minidump_config>;
#reset-cells = <1>;
};
};
@@ -2808,6 +2809,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x2e000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@28000 {
reg = <0x28000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 15/19] arm64: dts: qcom: sc7180: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index fa65c485172f..1f51fd431ce5 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -385,6 +385,7 @@ cluster_aoss_sleep: cluster-sleep-2 {
firmware {
scm: scm {
compatible = "qcom,scm-sc7180", "qcom,scm";
+ sram = <&minidump_config>;
};
};
@@ -3596,6 +3597,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x2e000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@28000 {
reg = <0x28000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 14/19] arm64: dts: qcom: sm8350: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index c830953156ec..dea97330da49 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -293,6 +293,7 @@ firmware {
scm: scm {
compatible = "qcom,scm-sm8350", "qcom,scm";
qcom,dload-mode = <&tcsr 0x13000>;
+ sram = <&minidump_config>;
#reset-cells = <1>;
};
};
@@ -3451,6 +3452,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x40000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@3d000 {
reg = <0x3d000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 13/19] arm64: dts: qcom: sc7280: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index fa540d8c2615..6d805cbe5b4f 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -720,6 +720,7 @@ firmware {
scm: scm {
compatible = "qcom,scm-sc7280", "qcom,scm";
qcom,dload-mode = <&tcsr_2 0x13000>;
+ sram = <&minidump_config>;
};
};
@@ -6698,6 +6699,10 @@ sram@146a5000 {
ranges = <0 0 0x146a5000 0x6000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@3000 {
reg = <0x3000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 12/19] arm64: dts: qcom: sm8650: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 160ead25ecf7..88751d3b72cd 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -645,6 +645,7 @@ scm: scm {
qcom,dload-mode = <&tcsr 0x19000>;
interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ sram = <&minidump_config>;
};
};
@@ -7091,6 +7092,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x2c000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@8000 {
reg = <0x8000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 11/19] arm64: dts: qcom: sm8550: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 396201905ef2..8830da63261f 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -391,6 +391,7 @@ scm: scm {
qcom,dload-mode = <&tcsr 0x19000>;
interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ sram = <&minidump_config>;
};
};
@@ -5537,6 +5538,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x2c000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@8000 {
reg = <0x8000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 10/19] arm64: dts: qcom: qdu1000: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qdu1000.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qdu1000.dtsi b/arch/arm64/boot/dts/qcom/qdu1000.dtsi
index 952d4270d118..0c6ae3ff06fb 100644
--- a/arch/arm64/boot/dts/qcom/qdu1000.dtsi
+++ b/arch/arm64/boot/dts/qcom/qdu1000.dtsi
@@ -171,6 +171,7 @@ cluster_sleep_1: cluster-sleep-1 {
firmware {
scm {
compatible = "qcom,scm-qdu1000", "qcom,scm";
+ sram = <&minidump_config>;
};
};
@@ -1369,6 +1370,10 @@ sram@14680000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@94c {
compatible = "qcom,pil-reloc-info";
reg = <0x94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 09/19] arm64: dts: qcom: qcs8300: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index e4c8466f941b..a05b8d28bdb8 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -634,6 +634,7 @@ firmware {
scm: scm {
compatible = "qcom,scm-qcs8300", "qcom,scm";
qcom,dload-mode = <&tcsr 0x13000>;
+ sram = <&minidump_config>;
};
};
@@ -7154,6 +7155,10 @@ sram: sram@146d8000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@94c {
compatible = "qcom,pil-reloc-info";
reg = <0x94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 08/19] arm64: dts: qcom: sa8775p: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 353a6e6fd3ac..a1708bd15076 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -524,6 +524,7 @@ firmware {
scm {
compatible = "qcom,scm-sa8775p", "qcom,scm";
qcom,dload-mode = <&tcsr 0x13000>;
+ sram = <&minidump_config>;
};
};
@@ -6825,6 +6826,10 @@ sram: sram@146d8000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@94c {
compatible = "qcom,pil-reloc-info";
reg = <0x94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 07/19] arm64: dts: qcom: sm8450: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 56cb6e959e4e..f819b4f7fdbc 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -479,6 +479,7 @@ scm: scm {
compatible = "qcom,scm-sm8450", "qcom,scm";
qcom,dload-mode = <&tcsr 0x13000>;
interconnects = <&aggre2_noc MASTER_CRYPTO 0 &mc_virt SLAVE_EBI1 0>;
+ sram = <&minidump_config>;
#reset-cells = <1>;
};
};
@@ -4978,6 +4979,10 @@ sram@146aa000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@94c {
compatible = "qcom,pil-reloc-info";
reg = <0x94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 06/19] arm64: dts: qcom: kaanapali: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7aa9653bd456..0342fd28f9b9 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -224,6 +224,7 @@ 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>;
};
scmi: scmi {
@@ -5452,6 +5453,10 @@ sram@14680000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-sram@94c {
compatible = "qcom,pil-reloc-info";
reg = <0x94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 05/19] firmware: qcom: scm: Add minidump SRAM support
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
On most Qualcomm SoCs where minidump is supported, a word in always-on
SRAM is shared between the operating system (OS) and boot firmware.
Before DDR is initialized 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 OS is expected to select one of the destinations.
The SRAM region is described by a 'sram' phandle 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.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/firmware/qcom/qcom_scm.c | 92 ++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 83e4810f1c53..ba5cdeed8a04 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,20 @@ 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 struct {
+ const char *name;
+ u32 val;
+} minidump_dest_map[] = {
+ { "usb", QCOM_MINIDUMP_DEST_USB },
+ { "storage", QCOM_MINIDUMP_DEST_STORAGE },
+};
+
#define QCOM_SCM_DEFAULT_WAITQ_COUNT 1
static const char * const qcom_scm_convention_names[] = {
@@ -568,6 +583,14 @@ static void qcom_scm_set_download_mode(struct qcom_scm *scm, u32 dload_mode)
if (ret)
dev_err(scm->dev, "failed to set download mode: %d\n", ret);
+
+ /*
+ * Write 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;
+ */
+ if (scm->minidump_sram && (dload_mode & QCOM_DLOAD_MINIDUMP))
+ writel_relaxed(minidump_dest, scm->minidump_sram);
}
/**
@@ -2040,6 +2063,29 @@ 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;
+
+ sram_np = of_parse_phandle(np, "sram", 0);
+ if (!sram_np)
+ return 0;
+
+ ret = of_address_to_resource(sram_np, 0, &res);
+ of_node_put(sram_np);
+ if (ret)
+ return ret;
+
+ *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;
@@ -2737,6 +2783,47 @@ 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_map); i++)
+ if (minidump_dest == minidump_dest_map[i].val)
+ return sysfs_emit(buffer, "%s\n", minidump_dest_map[i].name);
+
+ return sysfs_emit(buffer, "unknown\n");
+}
+
+static int set_minidump_dest(const char *val, const struct kernel_param *kp)
+{
+ struct qcom_scm *scm;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(minidump_dest_map); i++)
+ if (sysfs_streq(val, minidump_dest_map[i].name))
+ break;
+
+ if (i >= ARRAY_SIZE(minidump_dest_map))
+ return -EINVAL;
+
+ minidump_dest = minidump_dest_map[i].val;
+
+ /* Pairs with smp_store_release() in qcom_scm_probe(). */
+ scm = smp_load_acquire(&__scm);
+ if (scm && scm->minidump_sram && (download_mode & QCOM_DLOAD_MINIDUMP))
+ 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;
@@ -2754,6 +2841,11 @@ static int qcom_scm_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, ret,
"Failed to get 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
^ permalink raw reply related
* [PATCH v4 04/19] firmware: qcom: scm: use dev_err_probe() for dload address failure
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
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.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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 b78da40a4d60..83e4810f1c53 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2751,7 +2751,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 get download mode address\n");
mutex_init(&scm->scm_bw_lock);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 03/19] firmware: qcom: scm: Fix missing smp_load_acquire()
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
__scm is published in qcom_scm_probe() with smp_store_release()
but qcom_scm_set_download_mode() reads it directly without
smp_load_acquire(), creating a potential ordering violation where a
CPU could observe a stale or partially initialised __scm pointer.
Use smp_load_acquire() to acquire __scm in the
qcom_scm_set_download_mode() function.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/firmware/qcom/qcom_scm.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 6b601a4b89db..b78da40a4d60 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -551,23 +551,23 @@ static int qcom_scm_io_rmw(phys_addr_t addr, unsigned int mask, unsigned int val
return qcom_scm_io_writel(addr, new);
}
-static void qcom_scm_set_download_mode(u32 dload_mode)
+static void qcom_scm_set_download_mode(struct qcom_scm *scm, u32 dload_mode)
{
int ret = 0;
- if (__scm->dload_mode_addr) {
- ret = qcom_scm_io_rmw(__scm->dload_mode_addr, QCOM_DLOAD_MASK,
+ if (scm->dload_mode_addr) {
+ ret = qcom_scm_io_rmw(scm->dload_mode_addr, QCOM_DLOAD_MASK,
FIELD_PREP(QCOM_DLOAD_MASK, dload_mode));
- } else if (__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_BOOT,
+ } else if (__qcom_scm_is_call_available(scm->dev, QCOM_SCM_SVC_BOOT,
QCOM_SCM_BOOT_SET_DLOAD_MODE)) {
- ret = __qcom_scm_set_dload_mode(__scm->dev, !!dload_mode);
+ ret = __qcom_scm_set_dload_mode(scm->dev, !!dload_mode);
} else if (dload_mode) {
- dev_err(__scm->dev,
+ dev_err(scm->dev,
"No available mechanism for setting download mode\n");
}
if (ret)
- dev_err(__scm->dev, "failed to set download mode: %d\n", ret);
+ dev_err(scm->dev, "failed to set download mode: %d\n", ret);
}
/**
@@ -2705,6 +2705,7 @@ static int get_download_mode(char *buffer, const struct kernel_param *kp)
static int set_download_mode(const char *val, const struct kernel_param *kp)
{
+ struct qcom_scm *scm;
bool tmp;
int ret;
@@ -2720,8 +2721,10 @@ static int set_download_mode(const char *val, const struct kernel_param *kp)
}
download_mode = ret;
- if (__scm)
- qcom_scm_set_download_mode(download_mode);
+ /* Pairs with smp_store_release() in qcom_scm_probe(). */
+ scm = smp_load_acquire(&__scm);
+ if (scm)
+ qcom_scm_set_download_mode(scm, download_mode);
return 0;
}
@@ -2842,7 +2845,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
* will cause the boot stages to enter download mode, unless
* disabled below by a clean shutdown/reboot.
*/
- qcom_scm_set_download_mode(download_mode);
+ qcom_scm_set_download_mode(scm, download_mode);
/*
* Disable SDI if indicated by DT that it is enabled by default.
@@ -2875,7 +2878,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
static void qcom_scm_shutdown(struct platform_device *pdev)
{
/* Clean shutdown, disable download mode to allow normal restart */
- qcom_scm_set_download_mode(QCOM_DLOAD_NODUMP);
+ qcom_scm_set_download_mode(__scm, QCOM_DLOAD_NODUMP);
}
static const struct of_device_id qcom_scm_dt_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 02/19] dt-bindings: sram: qcom,imem: Add minidump-sram pattern property
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
The qcom,imem binding describes a single word in always-on SRAM shared
between the operating system (OS) and boot firmware. Before DDR is
initialized on the warm reset following a crash, firmware reads this
word to decide where to deliver the minidump, and the OS is expected to
select one of the destinations: either USB upload to a host PC or save
to on-device storage. If nothing is selected by the OS, USB is the
default.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
.../devicetree/bindings/sram/qcom,imem.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index c63026904061..17adced6d3a4 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -67,6 +67,22 @@ properties:
$ref: /schemas/power/reset/syscon-reboot-mode.yaml#
patternProperties:
+ "^minidump-sram@[0-9a-f]+$":
+ type: object
+ description:
+ A word in always-on SRAM shared between the kernel and boot firmware.
+ Before DDR is initialised on the warm reset following a crash, firmware
+ reads this word to decide where to deliver the minidump (USB or storage).
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ additionalProperties: false
+
"^modem-tables@[0-9a-f]+$":
type: object
description:
--
2.53.0
^ permalink raw reply related
* [PATCH v4 01/19] dt-bindings: firmware: qcom,scm: Add minidump SRAM property
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
On Qualcomm SoCs that support minidump, a word in always-on SRAM
is shared between the Operating System(HLOS) and boot firmware.
OS is expected to select the minidump download destination
either USB upload to a host PC or save to on-device storage.
Boot firmware will reads this word before DDR is initialized
on the warm reset following a crash to decide where to deliver
the minidump.
Add a 'sram' property to the SCM binding to allow the OS to
identify this SRAM region via a phandle.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index 25f62bacbc91..2d68b4065341 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -129,6 +129,13 @@ properties:
- description: offset of the download mode control register
description: TCSR hardware block
+ sram:
+ 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
+
allOf:
# Clocks
- if:
--
2.53.0
^ permalink raw reply related
* [PATCH v4 00/19] firmware: qcom: scm: Add minidump SRAM destination support
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha
On most Qualcomm SoCs where minidump is supported, a word in
always-on SRAM is shared between the operating system (OS) 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:
destination (USB upload to a host, or save to local storage) and
OS is expected to select one destination.
This series wires that mechanism into the SCM driver:
[1]- The SRAM word location is described via a 'sram' phandle on the
SCM DT node.
[2]- Add minidump-sram pattern property for older soc which supports
minidump destination support.
[3-4]- Trivial change for consistency.
[5]- A 'minidump_dest' module parameter (default: usb) selects the
destination. Custom kernel_param_ops expose it as the human-
readable strings "usb" or "storage".
[6-19]- Add the support for Kaanapali and other various SoCs.
Change in v4: https://lore.kernel.org/all/20260522195009.2961022-1-mukesh.ojha@oss.qualcomm.com/
- Refactor commit text for 1, 2, 5.
- added new commit(3/19) for existing issue reported by Sasiko .
Changes in v3: https://lore.kernel.org/lkml/20260519171442.1582987-1-mukesh.ojha@oss.qualcomm.com/
- Addressed some code improvement comments.
- Removed example from scm binding.
- Added minidump-sram binding which follows qcom,imem binding.
- Added some more SoCs which supports this .
Changes in v2: https://lore.kernel.org/lkml/20260507080727.3227367-1-mukesh.ojha@oss.qualcomm.com/
- Remove the restriction on the binding change done in v1.
- Remove sram-name from binding.
- sram definition is introduced and merged, so removed the refs from
v1.
- Minor change in the log as per comment s/find/get/
- remove reference of sram-names
- use minidump-sram instead of minidump-config.
Mukesh Ojha (19):
dt-bindings: firmware: qcom,scm: Add minidump SRAM property
dt-bindings: sram: qcom,imem: Add minidump-sram pattern property
firmware: qcom: scm: Fix missing smp_load_acquire()
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
arm64: dts: qcom: sm8450: Add minidump SRAM config to SCM node
arm64: dts: qcom: sa8775p: Add minidump SRAM config to SCM node
arm64: dts: qcom: qcs8300: Add minidump SRAM config to SCM node
arm64: dts: qcom: qdu1000: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm8550: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm8650: Add minidump SRAM config to SCM node
arm64: dts: qcom: sc7280: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm8350: Add minidump SRAM config to SCM node
arm64: dts: qcom: sc7180: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm6350: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm6375: Add minidump SRAM config to SCM node
arm64: dts: qcom: qcs615: Add minidump SRAM config to SCM node
arm64: dts: qcom: sdm845: Add minidump SRAM config to SCM node
.../bindings/firmware/qcom,scm.yaml | 7 +
.../devicetree/bindings/sram/qcom,imem.yaml | 16 +++
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 5 +
arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 +
arch/arm64/boot/dts/qcom/lemans.dtsi | 5 +
arch/arm64/boot/dts/qcom/monaco.dtsi | 5 +
arch/arm64/boot/dts/qcom/qdu1000.dtsi | 5 +
arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm6350.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm6375.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8350.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8450.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8650.dtsi | 5 +
arch/arm64/boot/dts/qcom/talos.dtsi | 5 +
drivers/firmware/qcom/qcom_scm.c | 120 ++++++++++++++++--
17 files changed, 201 insertions(+), 12 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH V14 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: sashiko-bot @ 2026-06-24 18:54 UTC (permalink / raw)
To: Chris Morgan; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260624182350.50467-6-macroalpha82@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The driver incorrectly uses the non-monotonic `ktime_get_real()` to measure the 45ms gyroscope power-off delay, risking bypassed hardware waits.
--
commit d9cd3cdeff3488026816468ab782366517d43120
Author: Chris Morgan <macromorgan@hotmail.com>
Subject: iio: imu: inv_icm42607: Add PM support for icm42607
Add power management support for the ICM42607 device driver.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 9b82a0499d35b..ad23386a37b78 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
[ ... ]
> @@ -102,6 +106,71 @@ const struct inv_icm42607_hw inv_icm42607p_hw_data = {
> };
> EXPORT_SYMBOL_NS_GPL(inv_icm42607p_hw_data, "IIO_ICM42607");
>
> +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> + enum inv_icm42607_sensor_mode gyro,
> + enum inv_icm42607_sensor_mode accel)
> +{
> + unsigned int oldaccel, oldgyro;
> + unsigned int sleepval_us = 0;
> + unsigned int val;
> + s64 disable_wait;
> + int ret;
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_PWR_MGMT0, &val);
> + if (ret)
> + return ret;
> +
> + oldaccel = FIELD_GET(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, val);
> + oldgyro = FIELD_GET(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, val);
> +
> + if (gyro == oldgyro && accel == oldaccel)
> + return 0;
> +
> + /*
> + * Datasheet on page 14.26 says we need to ensure the gyro sensor is on
> + * for a minimum of 45ms. So if we transition from an on state to an
> + * off state make sure at least 45ms have passed before power off and
> + * wait if it hasn't.
> + */
> + if (!gyro && oldgyro) {
> + disable_wait = ktime_us_delta(st->conf.gyro_stop,
> + ktime_get_real());
[Severity: Medium]
Is it safe to use the non-monotonic ktime_get_real() here to measure the
45ms gyroscope power-off delay?
If the system wall-clock (CLOCK_REALTIME) is stepped forward concurrently
(e.g., by an NTP sync), ktime_get_real() will jump forward. The calculated
disable_wait could become negative, get clamped to 0, and completely bypass
the mandatory wait before powering off the gyroscope, violating the datasheet
constraint.
Would it be better to use a monotonic clock like ktime_get() here and when
setting st->conf.gyro_stop below to track the elapsed interval reliably?
> + disable_wait = clamp(disable_wait, 0,
> + INV_ICM42607_GYRO_STOP_TIME_US);
> + fsleep(disable_wait);
> + }
> +
> + val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
> + val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
> + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> + if (ret)
> + return ret;
> +
> + /*
> + * If a state change occurs from off to on, sleep for the startup
> + * time of the sensor, unless a sleep_ms is specified. Since more
> + * than one sensor can be transitioned from off to on, select the
> + * maximum time from each of the sensors changing from off to on.
> + * The startup time for the temp sensor is considerably smaller
> + * than the startup time for the other sensors and one or more are
> + * required to be on for the temp sensor to function, so any start
> + * delay should be enough.
> + */
> + if (accel && !oldaccel)
> + sleepval_us = max(sleepval_us, INV_ICM42607_ACCEL_STARTUP_TIME_US);
> +
> + if (gyro && !oldgyro) {
> + sleepval_us = max(sleepval_us, INV_ICM42607_GYRO_STARTUP_TIME_US);
> + /* Track the earliest we can turn off the gyroscope. */
> + st->conf.gyro_stop = ktime_add_us(ktime_get_real(),
> + INV_ICM42607_GYRO_STOP_TIME_US);
> + }
> +
> + fsleep(sleepval_us);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624182350.50467-1-macroalpha82@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH V14 8/9] iio: imu: inv_icm42607: Add Temp Support in icm42607
From: sashiko-bot @ 2026-06-24 18:51 UTC (permalink / raw)
To: Chris Morgan; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260624182350.50467-9-macroalpha82@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing endianness initialization in INV_ICM42607_TEMP_CHAN.
- [Low] Leftover commented-out developmental code.
--
commit a30ed1de671168873a3fd8263c138bbcda62583a
Author: Chris Morgan <macromorgan@hotmail.com>
iio: imu: inv_icm42607: Add Temp Support in icm42607
Add functions for reading temperature sensor data.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> new file mode 100644
> index 0000000000000..f7e286ecb5cd6
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
[ ... ]
> +static int inv_icm42607_temp_read(struct inv_icm42607_state *st, s16 *temp)
> +{
[ ... ]
> + accel_mode = FIELD_GET(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, val);
> + gyro_mode = FIELD_GET(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, val);
> + if (!gyro_mode && !accel_mode) {
> + /* enable accel sensor */
> + conf.mode = INV_ICM42607_SENSOR_MODE_LOW_NOISE;
> +// ret = inv_icm42607_set_accel_conf(st, &conf);
[Severity: Low]
This isn't a bug, but should this commented-out line of code be removed
from the final patch?
> + ret = inv_icm42607_set_sensor_conf(st, &conf, IIO_ACCEL);
> + if (ret)
> + return ret;
> + }
[ ... ]
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
> new file mode 100644
> index 0000000000000..cb7b460ffb441
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
[ ... ]
> +#define INV_ICM42607_TEMP_CHAN(_index) \
> +{ \
> + .type = IIO_TEMP, \
> + .info_mask_separate = \
> + BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_OFFSET) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_shared_by_all = \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .info_mask_shared_by_all_available = \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .scan_index = _index, \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = 16, \
> + .storagebits = 16, \
> + }, \
[Severity: Low]
Does this scan_type struct need its endianness field initialized to IIO_BE?
Since get_unaligned_be16() is used when reading the sensor data in
inv_icm42607_temp_read(), it appears the hardware outputs big-endian data.
Omitting the endianness here defaults to IIO_CPU (0), which differs from the
gyro and accel channels that explicitly define it. Could this cause issues
if IIO buffered reads are implemented later?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624182350.50467-1-macroalpha82@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH V14 6/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: sashiko-bot @ 2026-06-24 18:50 UTC (permalink / raw)
To: Chris Morgan; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260624182350.50467-7-macroalpha82@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing update of software cache for sensor power mode causes unintended hardware power-downs.
- [Medium] Use of non-monotonic `ktime_get_real()` for hardware delay tracking.
--
commit 99de30070cdb6e08bed49a3aac077583415f3f84
Author: Chris Morgan <macromorgan@hotmail.com>
Subject: iio: imu: inv_icm42607: Add Accelerometer for icm42607
This patch adds accelerometer sensor support for the icm42607 device.
It introduces the accelerometer IIO channel configurations and integrates
the sensor state management.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index ad23386a37b78..26cedec0c97ce 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
[ ... ]
> @@ -106,6 +107,15 @@ const struct inv_icm42607_hw inv_icm42607p_hw_data = {
[ ... ]
> +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> + enum inv_icm42607_sensor_mode gyro,
> + enum inv_icm42607_sensor_mode accel)
> +{
[ ... ]
> + if (!gyro && oldgyro) {
> + disable_wait = ktime_us_delta(st->conf.gyro_stop,
> + ktime_get_real());
[Severity: Medium]
Is ktime_get_real() safe to use here for hardware delay tracking?
Because ktime_get_real() returns wall-clock time, it is susceptible to
time jumps, such as an NTP synchronization.
If the clock jumps forwards while the gyroscope is being powered off,
could the calculated disable_wait become negative and get clamped to 0,
thereby bypassing the 45ms minimum on-time requirement?
> + disable_wait = clamp(disable_wait, 0,
> + INV_ICM42607_GYRO_STOP_TIME_US);
> + fsleep(disable_wait);
> + }
[ ... ]
> + if (gyro && !oldgyro) {
> + sleepval_us = max(sleepval_us, INV_ICM42607_GYRO_STARTUP_TIME_US);
> + /* Track the earliest we can turn off the gyroscope. */
> + st->conf.gyro_stop = ktime_add_us(ktime_get_real(),
> + INV_ICM42607_GYRO_STOP_TIME_US);
[Severity: Medium]
Would using a monotonic time source like ktime_get() prevent potential
issues with time jumps during this delay calculation?
> + }
> +
> + fsleep(sleepval_us);
> +
> + return 0;
> +}
[ ... ]
> @@ -171,6 +181,160 @@ static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
[ ... ]
> +int inv_icm42607_set_sensor_conf(struct inv_icm42607_state *st,
> + struct inv_icm42607_sensor_conf *conf,
> + enum iio_chan_type chan_type)
> +{
[ ... ]
> + if (chan_type == IIO_ANGL_VEL)
> + return inv_icm42607_set_pwr_mgmt0(st, conf->mode, st->conf.accel.mode);
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode, conf->mode);
> +}
[Severity: High]
Does this code update the software state cache for the sensor mode?
It appears that inv_icm42607_set_sensor_conf() applies the new mode to
the hardware by calling inv_icm42607_set_pwr_mgmt0(), but returns without
saving conf->mode into oldconf->mode (or st->conf.accel.mode /
st->conf.gyro.mode).
If this cache remains at its initial OFF value, could a subsequent
configuration of the other sensor read this stale OFF state and
erroneously power down the currently active sensor?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624182350.50467-1-macroalpha82@gmail.com?part=6
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox