From fd75c2d01a50d877b375786abbeb179564ea8ffc Mon Sep 17 00:00:00 2001 From: Siddharth Gupta Date: Tue, 5 Jul 2022 17:38:20 +0530 Subject: [PATCH] remoteproc: sysmon: Send sysmon state only for running rprocs When a new remoteproc boots up, send the sysmon state notification of only running remoteprocs. Sending state of remoteprocs booting up in parallel can cause a race between SSR clients of the remoteproc that is booting up and the sysmon notification for the same remoteproc, resulting in an inconsistency between which state the remoteproc that is booting up in parallel. For example - if remoteproc A and B crash one after the other, after remoteproc A boots up, if the remoteproc A tries to get the state of remoteproc B before the sysmon subdevice for B is invoked but after the ssr subdevice of B has been invoked, clients on remoteproc A might get confused when the sysmon notification indicates a different state. Signed-off-by: Siddharth Gupta Signed-off-by: Sibi Sankar Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1657022900-2049-8-git-send-email-quic_sibis@quicinc.com --- drivers/remoteproc/qcom_sysmon.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c index a9f04dd..57dde2a 100644 --- a/drivers/remoteproc/qcom_sysmon.c +++ b/drivers/remoteproc/qcom_sysmon.c @@ -512,10 +512,12 @@ static int sysmon_start(struct rproc_subdev *subdev) mutex_lock(&sysmon_lock); list_for_each_entry(target, &sysmon_list, node) { - if (target == sysmon) + mutex_lock(&target->state_lock); + if (target == sysmon || target->state != SSCTL_SSR_EVENT_AFTER_POWERUP) { + mutex_unlock(&target->state_lock); continue; + } - mutex_lock(&target->state_lock); event.subsys_name = target->name; event.ssr_event = target->state; -- 2.7.4