* [PATCH v2 0/2] remoteproc: qcom: pas: Fix early_boot attach for not running and crashed remotes
@ 2026-10-11 2:28 Shawn Guo
2026-10-11 2:28 ` [PATCH v2 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time Shawn Guo
2026-10-11 2:28 ` [PATCH v2 2/2] remoteproc: qcom: pas: Don't fail attach if the remote has crashed Shawn Guo
0 siblings, 2 replies; 5+ messages in thread
From: Shawn Guo @ 2026-10-11 2:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Stephan Gerhold, Konrad Dybcio, Jingyi Wang,
Bartosz Golaszewski, linux-arm-msm, linux-remoteproc,
linux-kernel, Shawn Guo
The late attach support for early_boot subsystems has two problems.
1) A remote that the bootloader did not start is never booted. The
checks for that case live in qcom_pas_attach(), which marks the rproc
RPROC_OFFLINE and fails, but the core treats the failure as fatal and
never loads the firmware. This shows up on Nord, where newer XBL
firmware for the IoT variant leaves ADSP in reset for Linux to boot:
remoteproc remoteproc0: can't attach to rproc adsp: -19
Patch 1 moves the ready/stop-ack/shutdown-ack checks into probe, as
these signals are static until Linux interacts with the remote, and
only marks the rproc RPROC_DETACHED if the remote is running.
2) A remote found crashed at attach is recovered on top of the state the
failed attach has already unwound. Recovery leaves the rproc running
with a zero power refcount, so a following sysfs stop is a no-op and
start boots the firmware again on the running remote. Patch 2 lets
the attach succeed after reporting the crash, as the fatal interrupt
handler does, so recovery runs from the attached state.
This replaces the earlier patch dropping the early_boot flag from Nord
ADSP, following Konrad's and Stephan's comments [1]. With this series
the flag is kept, since the Nord Auto variant still has ADSP started by
XBL.
Changes for v2:
- Reword the "not attaching" info messages, as early_boot doesn't imply
auto_boot
- Factor crash handling out of q6v5_fatal_interrupt() into
qcom_q6v5_report_fatal() and use it in qcom_pas_attach() so the SMEM
crash reason is logged
- Link to v1: https://lore.kernel.org/all/20261006033550.2726451-1-shengchao.guo@oss.qualcomm.com/
[1] https://lore.kernel.org/r/20260930020745.1940933-1-shengchao.guo@oss.qualcomm.com/
Shawn Guo (2):
remoteproc: qcom: pas: Decide early_boot attach at probe time
remoteproc: qcom: pas: Don't fail attach if the remote has crashed
drivers/remoteproc/qcom_q6v5.c | 22 ++++++---
drivers/remoteproc/qcom_q6v5.h | 1 +
drivers/remoteproc/qcom_q6v5_pas.c | 71 ++++++++++++++++--------------
3 files changed, 56 insertions(+), 38 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time
2026-10-11 2:28 [PATCH v2 0/2] remoteproc: qcom: pas: Fix early_boot attach for not running and crashed remotes Shawn Guo
@ 2026-10-11 2:28 ` Shawn Guo
2026-10-12 8:48 ` Stephan Gerhold
2026-10-11 2:28 ` [PATCH v2 2/2] remoteproc: qcom: pas: Don't fail attach if the remote has crashed Shawn Guo
1 sibling, 1 reply; 5+ messages in thread
From: Shawn Guo @ 2026-10-11 2:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Stephan Gerhold, Konrad Dybcio, Jingyi Wang,
Bartosz Golaszewski, linux-arm-msm, linux-remoteproc,
linux-kernel, Shawn Guo
For early_boot subsystems, probe unconditionally marks the rproc
RPROC_DETACHED and qcom_pas_attach() discovers from SMP2P whether the
bootloader actually started the remote. If it did not, attach sets the
state back to RPROC_OFFLINE and fails, expecting the core to boot the
firmware instead. The core does not do that: rproc_boot() treats the
attach failure as fatal and the remote is never started.
This is hit on Nord with firmware where XBL no longer brings ADSP out
of reset. The remote never publishes its inbound SMP2P entries, so the
very first state read fails (debug print below) and the ADSP stays down:
qcom_q6v5_pas 4c00000.remoteproc: Failed to get fatal_irq state: -19
remoteproc remoteproc0: can't attach to rproc adsp: -19
The ready, stop-ack and sysmon shutdown-ack signals cannot change while
Linux has not yet interacted with the remote, so there is no reason to
defer the decision to attach time. Check them in probe and only mark
the rproc RPROC_DETACHED when the remote is up and has not been asked
to stop; otherwise leave it RPROC_OFFLINE so the regular firmware boot
path is taken. The ready state is read first so that a missing SMP2P
entry -ENODEV is treated as "not running" before sysmon is queried.
qcom_pas_attach() keeps only the fatal check, since that is the one
signal that has to be acted upon once the rproc is attached.
Assisted-by: LLM
Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
drivers/remoteproc/qcom_q6v5_pas.c | 64 +++++++++++++++---------------
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index 2e1e39826ffa..56179b71fd2a 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -550,9 +550,7 @@ static unsigned long qcom_pas_panic(struct rproc *rproc)
static int qcom_pas_attach(struct rproc *rproc)
{
struct qcom_pas *pas = rproc->priv;
- bool ready_state;
bool crash_state;
- bool stop_state;
int ret;
pas->q6v5.handover_issued = true;
@@ -570,42 +568,46 @@ static int qcom_pas_attach(struct rproc *rproc)
goto disable_running;
}
- ret = irq_get_irqchip_state(pas->q6v5.stop_irq,
- IRQCHIP_STATE_LINE_LEVEL, &stop_state);
- if (ret)
- goto disable_running;
-
- if (stop_state || qcom_sysmon_shutdown_irq_state(pas->sysmon)) {
- dev_info(pas->dev, "Subsystem found stop state set. Falling back to start.\n");
- goto unroll_attach;
- }
-
- ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
- IRQCHIP_STATE_LINE_LEVEL, &ready_state);
- if (ret)
- goto disable_running;
-
- if (unlikely(!ready_state)) {
- /*
- * The bootloader may not support early boot, mark the state as
- * RPROC_OFFLINE so that the PAS driver can load the firmware and
- * start the remoteproc.
- */
- dev_err(pas->dev, "Failed to get subsystem ready interrupt\n");
- goto unroll_attach;
- }
-
return 0;
-unroll_attach:
- pas->rproc->state = RPROC_OFFLINE;
- ret = -EINVAL;
disable_running:
pas->q6v5.running = false;
return ret;
}
+/*
+ * The bootloader may or may not have started the subsystem. Inspect the
+ * SMP2P state, which is static until Linux interacts with the remote, to
+ * decide whether to attach or to load and start the firmware.
+ */
+static bool qcom_pas_is_running(struct qcom_pas *pas)
+{
+ bool ready_state;
+ bool stop_state;
+ int ret;
+
+ /*
+ * Check ready first: if the remote never published its SMP2P
+ * entries the state read fails with -ENODEV.
+ */
+ ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
+ IRQCHIP_STATE_LINE_LEVEL, &ready_state);
+ if (ret || !ready_state) {
+ dev_info(pas->dev, "Subsystem not running, not attaching\n");
+ return false;
+ }
+
+ ret = irq_get_irqchip_state(pas->q6v5.stop_irq,
+ IRQCHIP_STATE_LINE_LEVEL, &stop_state);
+ if (ret || stop_state || qcom_sysmon_shutdown_irq_state(pas->sysmon)) {
+ dev_info(pas->dev, "Subsystem found stop state set, not attaching\n");
+ return false;
+ }
+
+ return true;
+}
+
static void qcom_pas_coredump(struct rproc *rproc)
{
struct qcom_pas *pas = rproc->priv;
@@ -1024,7 +1026,7 @@ static int qcom_pas_probe(struct platform_device *pdev)
if (pas->dtb_pas_id)
pas->dtb_pas_ctx->use_tzmem = desc->needs_tzmem || rproc->has_iommu;
- if (desc->early_boot)
+ if (desc->early_boot && qcom_pas_is_running(pas))
pas->rproc->state = RPROC_DETACHED;
ret = qcom_pas_setup_tmd(pas, desc);
--
2.43.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 2/2] remoteproc: qcom: pas: Don't fail attach if the remote has crashed
2026-10-11 2:28 [PATCH v2 0/2] remoteproc: qcom: pas: Fix early_boot attach for not running and crashed remotes Shawn Guo
2026-10-11 2:28 ` [PATCH v2 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time Shawn Guo
@ 2026-10-11 2:28 ` Shawn Guo
2026-10-12 8:50 ` Stephan Gerhold
1 sibling, 1 reply; 5+ messages in thread
From: Shawn Guo @ 2026-10-11 2:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mathieu Poirier, Stephan Gerhold, Konrad Dybcio, Jingyi Wang,
Bartosz Golaszewski, linux-arm-msm, linux-remoteproc,
linux-kernel, Shawn Guo
When qcom_pas_attach() finds the fatal SMP2P bit already set, it reports
a crash and then fails the attach. The core unwinds the attach while the
crash work is queued: rproc_boot() drops the power refcount back to 0,
and __rproc_attach()/rproc_attach() unprepare the subdevices, clean up
the resource table and disable the IOMMU. Once rproc_boot() releases
rproc->lock, the crash handler finds the rproc still RPROC_DETACHED,
marks it RPROC_CRASHED and runs rproc_boot_recovery() on top of that
torn-down state:
- the subdevices are unprepared a second time by rproc_stop(), so SSR
and sysmon notifiers see a duplicate shutdown;
- qcom_pas_stop() and the subsequent rproc_start() operate on resources
that rproc_attach() already released, e.g. iommu_unmap() on a
disabled domain for rproc->has_iommu;
- recovery leaves the rproc RPROC_RUNNING with power == 0. A later
"stop" via sysfs takes power to -1 and returns success without
stopping anything, so the remote stays running. A following "start"
then boots the firmware again on the running remote and fails to
re-add the still registered subdevices:
sysfs: cannot create duplicate filename '.../qcom_common.pd-mapper.0'
remoteproc remoteproc0: failed to prepare subdevices for adsp: -17
remoteproc remoteproc0: Boot failed: -17
A crash found at attach time is no different from one reported by the
fatal interrupt right after attaching. Factor the crash handling out of
q6v5_fatal_interrupt() into qcom_q6v5_report_fatal(), which logs the
SMEM crash reason, clears q6v5.running and reports the crash, and call
it from qcom_pas_attach() before letting the attach succeed. The core
completes the attach with balanced bookkeeping, and the crash handler
then recovers the subsystem through the regular RPROC_ATTACHED ->
RPROC_CRASHED path. With running cleared, qcom_q6v5_request_stop() does
not wait for a stop ack the dead remote cannot send, and handover_issued
already prevents a spurious handover on stop.
Assisted-by: LLM
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
drivers/remoteproc/qcom_q6v5.c | 22 +++++++++++++++++-----
drivers/remoteproc/qcom_q6v5.h | 1 +
drivers/remoteproc/qcom_q6v5_pas.c | 9 ++++++---
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index fe148b4b3775..51b24cbd4336 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -147,15 +147,18 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void *data)
return IRQ_HANDLED;
}
-static irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
+/**
+ * qcom_q6v5_report_fatal() - report a fatal error of the remote processor
+ * @q6v5: reference to qcom_q6v5 context
+ *
+ * Log the crash reason published by the remote in SMEM, mark the remote as
+ * no longer running and report the crash to the remoteproc core.
+ */
+void qcom_q6v5_report_fatal(struct qcom_q6v5 *q6v5)
{
- struct qcom_q6v5 *q6v5 = data;
size_t len;
char *msg;
- if (!q6v5->running)
- return IRQ_HANDLED;
-
msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, &len);
if (!IS_ERR(msg) && len > 0 && msg[0])
dev_err(q6v5->dev, "fatal error received: %s\n", msg);
@@ -164,6 +167,15 @@ static irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
q6v5->running = false;
rproc_report_crash(q6v5->rproc, RPROC_FATAL_ERROR);
+}
+EXPORT_SYMBOL_GPL(qcom_q6v5_report_fatal);
+
+static irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
+{
+ struct qcom_q6v5 *q6v5 = data;
+
+ if (q6v5->running)
+ qcom_q6v5_report_fatal(q6v5);
return IRQ_HANDLED;
}
diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
index 8991ff090579..a0507860a21c 100644
--- a/drivers/remoteproc/qcom_q6v5.h
+++ b/drivers/remoteproc/qcom_q6v5.h
@@ -56,5 +56,6 @@ int qcom_q6v5_unprepare(struct qcom_q6v5 *q6v5);
int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5, struct qcom_sysmon *sysmon);
int qcom_q6v5_wait_for_start(struct qcom_q6v5 *q6v5, int timeout);
unsigned long qcom_q6v5_panic(struct qcom_q6v5 *q6v5);
+void qcom_q6v5_report_fatal(struct qcom_q6v5 *q6v5);
#endif
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index 56179b71fd2a..99f627db6bd3 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -562,10 +562,13 @@ static int qcom_pas_attach(struct rproc *rproc)
goto disable_running;
if (crash_state) {
+ /*
+ * Complete the attach and let the crash handler recover the
+ * subsystem from the attached state, as for a crash reported
+ * by the fatal interrupt.
+ */
dev_err(pas->dev, "Subsystem has crashed before driver probe\n");
- rproc_report_crash(rproc, RPROC_FATAL_ERROR);
- ret = -EINVAL;
- goto disable_running;
+ qcom_q6v5_report_fatal(&pas->q6v5);
}
return 0;
--
2.43.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time
2026-10-11 2:28 ` [PATCH v2 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time Shawn Guo
@ 2026-10-12 8:48 ` Stephan Gerhold
0 siblings, 0 replies; 5+ messages in thread
From: Stephan Gerhold @ 2026-10-12 8:48 UTC (permalink / raw)
To: Shawn Guo
Cc: Bjorn Andersson, Mathieu Poirier, Konrad Dybcio, Jingyi Wang,
Bartosz Golaszewski, linux-arm-msm, linux-remoteproc,
linux-kernel
On Sun, Oct 11, 2026 at 10:28:01AM +0800, Shawn Guo wrote:
> For early_boot subsystems, probe unconditionally marks the rproc
> RPROC_DETACHED and qcom_pas_attach() discovers from SMP2P whether the
> bootloader actually started the remote. If it did not, attach sets the
> state back to RPROC_OFFLINE and fails, expecting the core to boot the
> firmware instead. The core does not do that: rproc_boot() treats the
> attach failure as fatal and the remote is never started.
>
> This is hit on Nord with firmware where XBL no longer brings ADSP out
> of reset. The remote never publishes its inbound SMP2P entries, so the
> very first state read fails (debug print below) and the ADSP stays down:
>
> qcom_q6v5_pas 4c00000.remoteproc: Failed to get fatal_irq state: -19
> remoteproc remoteproc0: can't attach to rproc adsp: -19
>
> The ready, stop-ack and sysmon shutdown-ack signals cannot change while
> Linux has not yet interacted with the remote, so there is no reason to
> defer the decision to attach time. Check them in probe and only mark
> the rproc RPROC_DETACHED when the remote is up and has not been asked
> to stop; otherwise leave it RPROC_OFFLINE so the regular firmware boot
> path is taken. The ready state is read first so that a missing SMP2P
> entry -ENODEV is treated as "not running" before sysmon is queried.
>
> qcom_pas_attach() keeps only the fatal check, since that is the one
> signal that has to be acted upon once the rproc is attached.
>
> Assisted-by: LLM
I think we should add stable/Fixes here for backporting to 6.3:
Cc: stable@vger.kernel.org
Fixes: 16472c99f469 ("remoteproc: qcom: pas: Add late attach support for subsystems")
I'm not sure if b4 picks up Cc/Fixes as trailers when applying so you
may need to resend.
> Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5_pas.c | 64 +++++++++++++++---------------
> 1 file changed, 33 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 2e1e39826ffa..56179b71fd2a 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -550,9 +550,7 @@ static unsigned long qcom_pas_panic(struct rproc *rproc)
> static int qcom_pas_attach(struct rproc *rproc)
> {
> struct qcom_pas *pas = rproc->priv;
> - bool ready_state;
> bool crash_state;
> - bool stop_state;
> int ret;
>
> pas->q6v5.handover_issued = true;
> @@ -570,42 +568,46 @@ static int qcom_pas_attach(struct rproc *rproc)
> goto disable_running;
> }
>
> - ret = irq_get_irqchip_state(pas->q6v5.stop_irq,
> - IRQCHIP_STATE_LINE_LEVEL, &stop_state);
> - if (ret)
> - goto disable_running;
> -
> - if (stop_state || qcom_sysmon_shutdown_irq_state(pas->sysmon)) {
> - dev_info(pas->dev, "Subsystem found stop state set. Falling back to start.\n");
> - goto unroll_attach;
> - }
> -
> - ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> - IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> - if (ret)
> - goto disable_running;
> -
> - if (unlikely(!ready_state)) {
> - /*
> - * The bootloader may not support early boot, mark the state as
> - * RPROC_OFFLINE so that the PAS driver can load the firmware and
> - * start the remoteproc.
> - */
> - dev_err(pas->dev, "Failed to get subsystem ready interrupt\n");
> - goto unroll_attach;
> - }
> -
> return 0;
>
> -unroll_attach:
> - pas->rproc->state = RPROC_OFFLINE;
> - ret = -EINVAL;
> disable_running:
> pas->q6v5.running = false;
>
> return ret;
> }
>
> +/*
> + * The bootloader may or may not have started the subsystem. Inspect the
> + * SMP2P state, which is static until Linux interacts with the remote, to
> + * decide whether to attach or to load and start the firmware.
> + */
> +static bool qcom_pas_is_running(struct qcom_pas *pas)
> +{
> + bool ready_state;
> + bool stop_state;
> + int ret;
> +
> + /*
> + * Check ready first: if the remote never published its SMP2P
> + * entries the state read fails with -ENODEV.
> + */
> + ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> + if (ret || !ready_state) {
> + dev_info(pas->dev, "Subsystem not running, not attaching\n");
> + return false;
> + }
> +
> + ret = irq_get_irqchip_state(pas->q6v5.stop_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &stop_state);
> + if (ret || stop_state || qcom_sysmon_shutdown_irq_state(pas->sysmon)) {
> + dev_info(pas->dev, "Subsystem found stop state set, not attaching\n");
Another nitpick from the original message, the subsystem is stopped so
it cannot find anything, "Subsystem *has* stop state set" would probably
be better. :-)
Thanks,
Stephan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 2/2] remoteproc: qcom: pas: Don't fail attach if the remote has crashed
2026-10-11 2:28 ` [PATCH v2 2/2] remoteproc: qcom: pas: Don't fail attach if the remote has crashed Shawn Guo
@ 2026-10-12 8:50 ` Stephan Gerhold
0 siblings, 0 replies; 5+ messages in thread
From: Stephan Gerhold @ 2026-10-12 8:50 UTC (permalink / raw)
To: Shawn Guo
Cc: Bjorn Andersson, Mathieu Poirier, Konrad Dybcio, Jingyi Wang,
Bartosz Golaszewski, linux-arm-msm, linux-remoteproc,
linux-kernel
On Sun, Oct 11, 2026 at 10:28:02AM +0800, Shawn Guo wrote:
> When qcom_pas_attach() finds the fatal SMP2P bit already set, it reports
> a crash and then fails the attach. The core unwinds the attach while the
> crash work is queued: rproc_boot() drops the power refcount back to 0,
> and __rproc_attach()/rproc_attach() unprepare the subdevices, clean up
> the resource table and disable the IOMMU. Once rproc_boot() releases
> rproc->lock, the crash handler finds the rproc still RPROC_DETACHED,
> marks it RPROC_CRASHED and runs rproc_boot_recovery() on top of that
> torn-down state:
>
> - the subdevices are unprepared a second time by rproc_stop(), so SSR
> and sysmon notifiers see a duplicate shutdown;
> - qcom_pas_stop() and the subsequent rproc_start() operate on resources
> that rproc_attach() already released, e.g. iommu_unmap() on a
> disabled domain for rproc->has_iommu;
> - recovery leaves the rproc RPROC_RUNNING with power == 0. A later
> "stop" via sysfs takes power to -1 and returns success without
> stopping anything, so the remote stays running. A following "start"
> then boots the firmware again on the running remote and fails to
> re-add the still registered subdevices:
>
> sysfs: cannot create duplicate filename '.../qcom_common.pd-mapper.0'
> remoteproc remoteproc0: failed to prepare subdevices for adsp: -17
> remoteproc remoteproc0: Boot failed: -17
>
> A crash found at attach time is no different from one reported by the
> fatal interrupt right after attaching. Factor the crash handling out of
> q6v5_fatal_interrupt() into qcom_q6v5_report_fatal(), which logs the
> SMEM crash reason, clears q6v5.running and reports the crash, and call
> it from qcom_pas_attach() before letting the attach succeed. The core
> completes the attach with balanced bookkeeping, and the crash handler
> then recovers the subsystem through the regular RPROC_ATTACHED ->
> RPROC_CRASHED path. With running cleared, qcom_q6v5_request_stop() does
> not wait for a stop ack the dead remote cannot send, and handover_issued
> already prevents a spurious handover on stop.
>
> Assisted-by: LLM
Cc: stable@vger.kernel.org
Fixes: 16472c99f469 ("remoteproc: qcom: pas: Add late attach support for subsystems")
Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Thanks for the fixes!
Stephan
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5.c | 22 +++++++++++++++++-----
> drivers/remoteproc/qcom_q6v5.h | 1 +
> drivers/remoteproc/qcom_q6v5_pas.c | 9 ++++++---
> 3 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index fe148b4b3775..51b24cbd4336 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -147,15 +147,18 @@ static irqreturn_t q6v5_wdog_interrupt(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
> +/**
> + * qcom_q6v5_report_fatal() - report a fatal error of the remote processor
> + * @q6v5: reference to qcom_q6v5 context
> + *
> + * Log the crash reason published by the remote in SMEM, mark the remote as
> + * no longer running and report the crash to the remoteproc core.
> + */
> +void qcom_q6v5_report_fatal(struct qcom_q6v5 *q6v5)
> {
> - struct qcom_q6v5 *q6v5 = data;
> size_t len;
> char *msg;
>
> - if (!q6v5->running)
> - return IRQ_HANDLED;
> -
> msg = qcom_smem_get(QCOM_SMEM_HOST_ANY, q6v5->crash_reason, &len);
> if (!IS_ERR(msg) && len > 0 && msg[0])
> dev_err(q6v5->dev, "fatal error received: %s\n", msg);
> @@ -164,6 +167,15 @@ static irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
>
> q6v5->running = false;
> rproc_report_crash(q6v5->rproc, RPROC_FATAL_ERROR);
> +}
> +EXPORT_SYMBOL_GPL(qcom_q6v5_report_fatal);
> +
> +static irqreturn_t q6v5_fatal_interrupt(int irq, void *data)
> +{
> + struct qcom_q6v5 *q6v5 = data;
> +
> + if (q6v5->running)
> + qcom_q6v5_report_fatal(q6v5);
>
> return IRQ_HANDLED;
> }
> diff --git a/drivers/remoteproc/qcom_q6v5.h b/drivers/remoteproc/qcom_q6v5.h
> index 8991ff090579..a0507860a21c 100644
> --- a/drivers/remoteproc/qcom_q6v5.h
> +++ b/drivers/remoteproc/qcom_q6v5.h
> @@ -56,5 +56,6 @@ int qcom_q6v5_unprepare(struct qcom_q6v5 *q6v5);
> int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5, struct qcom_sysmon *sysmon);
> int qcom_q6v5_wait_for_start(struct qcom_q6v5 *q6v5, int timeout);
> unsigned long qcom_q6v5_panic(struct qcom_q6v5 *q6v5);
> +void qcom_q6v5_report_fatal(struct qcom_q6v5 *q6v5);
>
> #endif
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 56179b71fd2a..99f627db6bd3 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -562,10 +562,13 @@ static int qcom_pas_attach(struct rproc *rproc)
> goto disable_running;
>
> if (crash_state) {
> + /*
> + * Complete the attach and let the crash handler recover the
> + * subsystem from the attached state, as for a crash reported
> + * by the fatal interrupt.
> + */
> dev_err(pas->dev, "Subsystem has crashed before driver probe\n");
> - rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> - ret = -EINVAL;
> - goto disable_running;
> + qcom_q6v5_report_fatal(&pas->q6v5);
> }
>
> return 0;
> --
> 2.43.0
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-10-12 8:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-11 2:28 [PATCH v2 0/2] remoteproc: qcom: pas: Fix early_boot attach for not running and crashed remotes Shawn Guo
2026-10-11 2:28 ` [PATCH v2 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time Shawn Guo
2026-10-12 8:48 ` Stephan Gerhold
2026-10-11 2:28 ` [PATCH v2 2/2] remoteproc: qcom: pas: Don't fail attach if the remote has crashed Shawn Guo
2026-10-12 8:50 ` Stephan Gerhold
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®