| Message ID | 20250317114057.1725151-1-quic_schowdhu@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v3] remoteproc: Add device awake calls in rproc boot and shutdown path | expand |
On Mon, Mar 17, 2025 at 05:10:57PM +0530, Souradeep Chowdhury wrote: > Add device awake calls in case of rproc boot and rproc shutdown path. > Currently, device awake call is only present in the recovery path > of remoteproc. If a user stops and starts rproc by using the sysfs > interface, then on pm suspension the firmware loading fails. Keep the > device awake in such a case just like it is done for the recovery path. > Please rewrite this in the form expressed in https://docs.kernel.org/process/submitting-patches.html#describe-your-changes Clearly describe the problem you're solving - not just the change in behavior. What do you mean that "firmware loading fails" if we hit a suspend during stop and start through sysfs? At what point does it fail? > Fixes: a781e5aa59110 ("remoteproc: core: Prevent system suspend during remoteproc recovery") That patch clearly states that it intends to keep the system from suspending during recovery. As far as I can tell you're changing the start and stop sequences. As such, I don't think the referred to patch was broken and you're not fixing it. > Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> > Cc: stable@vger.kernel.org It's not clear to me from the commit message why this should be backported to stable kernel. > --- > Changes in v3 > > *Add the stability mailing list in commit message > > drivers/remoteproc/remoteproc_core.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index c2cf0d277729..908a7b8f6c7e 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1916,7 +1916,8 @@ int rproc_boot(struct rproc *rproc) > pr_err("invalid rproc handle\n"); > return -EINVAL; > } > - > + You're replacing an empty line with a tab... Other than that, the change looks sensible. Regards, Bjorn > + pm_stay_awake(rproc->dev.parent); > dev = &rproc->dev; > > ret = mutex_lock_interruptible(&rproc->lock); > @@ -1961,6 +1962,7 @@ int rproc_boot(struct rproc *rproc) > atomic_dec(&rproc->power); > unlock_mutex: > mutex_unlock(&rproc->lock); > + pm_relax(rproc->dev.parent); > return ret; > } > EXPORT_SYMBOL(rproc_boot); > @@ -1991,6 +1993,7 @@ int rproc_shutdown(struct rproc *rproc) > struct device *dev = &rproc->dev; > int ret = 0; > > + pm_stay_awake(rproc->dev.parent); > ret = mutex_lock_interruptible(&rproc->lock); > if (ret) { > dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret); > @@ -2027,6 +2030,7 @@ int rproc_shutdown(struct rproc *rproc) > rproc->table_ptr = NULL; > out: > mutex_unlock(&rproc->lock); > + pm_relax(rproc->dev.parent); > return ret; > } > EXPORT_SYMBOL(rproc_shutdown); > -- > 2.34.1 >
On 3/22/2025 3:51 AM, Bjorn Andersson wrote: > On Mon, Mar 17, 2025 at 05:10:57PM +0530, Souradeep Chowdhury wrote: >> Add device awake calls in case of rproc boot and rproc shutdown path. >> Currently, device awake call is only present in the recovery path >> of remoteproc. If a user stops and starts rproc by using the sysfs >> interface, then on pm suspension the firmware loading fails. Keep the >> device awake in such a case just like it is done for the recovery path. >> > Please rewrite this in the form expressed in > https://docs.kernel.org/process/submitting-patches.html#describe-your-changes > > Clearly describe the problem you're solving - not just the change in > behavior. > > What do you mean that "firmware loading fails" if we hit a suspend > during stop and start through sysfs? At what point does it fail? Ack. It fails under the request_firmware call made in adsp_load under drivers/remoteproc/qcom_q6v5_pas.c > >> Fixes: a781e5aa59110 ("remoteproc: core: Prevent system suspend during remoteproc recovery") > That patch clearly states that it intends to keep the system from > suspending during recovery. As far as I can tell you're changing the > start and stop sequences. > > As such, I don't think the referred to patch was broken and you're not > fixing it. Ack > >> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> >> Cc: stable@vger.kernel.org > It's not clear to me from the commit message why this should be > backported to stable kernel. Ack. Will remove stability from mailing list. > >> --- >> Changes in v3 >> >> *Add the stability mailing list in commit message >> >> drivers/remoteproc/remoteproc_core.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c >> index c2cf0d277729..908a7b8f6c7e 100644 >> --- a/drivers/remoteproc/remoteproc_core.c >> +++ b/drivers/remoteproc/remoteproc_core.c >> @@ -1916,7 +1916,8 @@ int rproc_boot(struct rproc *rproc) >> pr_err("invalid rproc handle\n"); >> return -EINVAL; >> } >> - >> + > You're replacing an empty line with a tab... Ack > > > Other than that, the change looks sensible. > > Regards, > Bjorn > >> + pm_stay_awake(rproc->dev.parent); >> dev = &rproc->dev; >> >> ret = mutex_lock_interruptible(&rproc->lock); >> @@ -1961,6 +1962,7 @@ int rproc_boot(struct rproc *rproc) >> atomic_dec(&rproc->power); >> unlock_mutex: >> mutex_unlock(&rproc->lock); >> + pm_relax(rproc->dev.parent); >> return ret; >> } >> EXPORT_SYMBOL(rproc_boot); >> @@ -1991,6 +1993,7 @@ int rproc_shutdown(struct rproc *rproc) >> struct device *dev = &rproc->dev; >> int ret = 0; >> >> + pm_stay_awake(rproc->dev.parent); >> ret = mutex_lock_interruptible(&rproc->lock); >> if (ret) { >> dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret); >> @@ -2027,6 +2030,7 @@ int rproc_shutdown(struct rproc *rproc) >> rproc->table_ptr = NULL; >> out: >> mutex_unlock(&rproc->lock); >> + pm_relax(rproc->dev.parent); >> return ret; >> } >> EXPORT_SYMBOL(rproc_shutdown); >> -- >> 2.34.1 >>
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index c2cf0d277729..908a7b8f6c7e 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1916,7 +1916,8 @@ int rproc_boot(struct rproc *rproc) pr_err("invalid rproc handle\n"); return -EINVAL; } - + + pm_stay_awake(rproc->dev.parent); dev = &rproc->dev; ret = mutex_lock_interruptible(&rproc->lock); @@ -1961,6 +1962,7 @@ int rproc_boot(struct rproc *rproc) atomic_dec(&rproc->power); unlock_mutex: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_boot); @@ -1991,6 +1993,7 @@ int rproc_shutdown(struct rproc *rproc) struct device *dev = &rproc->dev; int ret = 0; + pm_stay_awake(rproc->dev.parent); ret = mutex_lock_interruptible(&rproc->lock); if (ret) { dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret); @@ -2027,6 +2030,7 @@ int rproc_shutdown(struct rproc *rproc) rproc->table_ptr = NULL; out: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_shutdown);
Add device awake calls in case of rproc boot and rproc shutdown path. Currently, device awake call is only present in the recovery path of remoteproc. If a user stops and starts rproc by using the sysfs interface, then on pm suspension the firmware loading fails. Keep the device awake in such a case just like it is done for the recovery path. Fixes: a781e5aa59110 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Cc: stable@vger.kernel.org --- Changes in v3 *Add the stability mailing list in commit message drivers/remoteproc/remoteproc_core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)