Hi Dan,
I am not sure, Is this false alarm?
On Tue, Oct 14, 2025 at 11:39:41AM +0300, Dan Carpenter wrote:
>Hi Peng,
>
>
>vim +/ret +1841 drivers/remoteproc/remoteproc_core.c
>
>70b85ef83ce3523 Fernando Guzman Lugo 2012-08-30 1829 int
>rproc_trigger_recovery(struct rproc *rproc)
>70b85ef83ce3523 Fernando Guzman Lugo 2012-08-30 1830 {
>7e83cab824a8670 Sarangdhar Joshi 2017-05-26 1831 struct device
>*dev = &rproc->dev;
>7e83cab824a8670 Sarangdhar Joshi 2017-05-26 1832 int ret;
>7e83cab824a8670 Sarangdhar Joshi 2017-05-26 1833
>c42baf6f84c7694 Peng Fan 2025-10-10 1834
>ACQUIRE(mutex_intr, lock)(&rproc->lock);
>c42baf6f84c7694 Peng Fan 2025-10-10 1835 ret =
>ACQUIRE_ERR(mutex_intr, &lock);
>7e83cab824a8670 Sarangdhar Joshi 2017-05-26 1836 if (ret)
>7e83cab824a8670 Sarangdhar Joshi 2017-05-26 1837 return
>ret;
>7e83cab824a8670 Sarangdhar Joshi 2017-05-26 1838
>0b145574b6cd2b3 Alex Elder 2020-02-28 1839 /* State could
>have changed before we got the mutex */
>0b145574b6cd2b3 Alex Elder 2020-02-28 1840 if
>(rproc->state != RPROC_CRASHED)
>c42baf6f84c7694 Peng Fan 2025-10-10 @1841 return
>ret;
>
>Please change this to either "return 0;" or "return -ERRORCODE;"
ACQUIRE_ERR should already returns 0. This change does not change the
assignment to ret as my understanding. Please help to see if this is false
alarm or I miss something?
>
>400e64df6b237eb Ohad Ben-Cohen 2011-10-20 1980
>c42baf6f84c7694 Peng Fan 2025-10-10 1981
>ACQUIRE(mutex_intr, lock)(&rproc->lock);
>c42baf6f84c7694 Peng Fan 2025-10-10 1982 ret =
>ACQUIRE_ERR(mutex_intr, &lock);
>400e64df6b237eb Ohad Ben-Cohen 2011-10-20 1983 if (ret) {
>400e64df6b237eb Ohad Ben-Cohen 2011-10-20 1984
>dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret);
>c13b780c4597e1e Suman Anna 2022-02-13 1985 return
>ret;
>400e64df6b237eb Ohad Ben-Cohen 2011-10-20 1986 }
>400e64df6b237eb Ohad Ben-Cohen 2011-10-20 1987
>c42baf6f84c7694 Peng Fan 2025-10-10 1988 if
>(rproc->state != RPROC_RUNNING && rproc->state != RPROC_ATTACHED)
>c42baf6f84c7694 Peng Fan 2025-10-10 1989 return
>-EINVAL;
>5e6a0e05270e3a4 Shengjiu Wang 2022-03-28 1990
>400e64df6b237eb Ohad Ben-Cohen 2011-10-20 1991 /* if the
>remote proc is still needed, bail out */
>400e64df6b237eb Ohad Ben-Cohen 2011-10-20 1992 if
>(!atomic_dec_and_test(&rproc->power))
>c42baf6f84c7694 Peng Fan 2025-10-10 @1993 return
>ret;
>
>Same.
Same as above.
Thanks,
Peng
>
