Re: [PATCH v2 4/7] remoteproc: core: Use cleanup.h macros to simplify lock handling

Peng Fan
2025-10-14T09:33:24Z

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
>