[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZA7cZBF58yMSjG/+@hovoldconsulting.com>
Date: Mon, 13 Mar 2023 09:18:44 +0100
From: Johan Hovold <johan@...nel.org>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: johan+linaro@...nel.org, a.swigon@...sung.com, agross@...nel.org,
alim.akhtar@...sung.com, andersson@...nel.org, djakov@...nel.org,
festevam@...il.com, jonathanh@...dia.com, kernel@...gutronix.de,
konrad.dybcio@...aro.org, krzysztof.kozlowski@...aro.org,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-imx@....com,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-samsung-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
s.hauer@...gutronix.de, s.nawrocki@...sung.com,
shawnguo@...nel.org, stable@...r.kernel.org,
thierry.reding@...il.com, y.oudjana@...tonmail.com
Subject: Re: [PATCH 07/23] interconnect: qcom: rpm: fix probe PM domain error
handling
On Sat, Mar 11, 2023 at 07:17:50PM +0100, Christophe JAILLET wrote:
> Le 01/02/2023 à 11:15, Johan Hovold a écrit :
> > Make sure to disable clocks also in case attaching the power domain
> > fails.
> >
> > Fixes: 7de109c0abe9 ("interconnect: icc-rpm: Add support for bus power domain")
> > Cc: stable-u79uwXL29TY76Z2rM5mHXA@...lic.gmane.org # 5.17
> > Cc: Yassine Oudjana <y.oudjana-g/b1ySJe57IN+BqQ9rBEUg@...lic.gmane.org>
> > Signed-off-by: Johan Hovold <johan+linaro-DgEjT+Ai2ygdnm+yROfE0A@...lic.gmane.org>
> > ---
> > drivers/interconnect/qcom/icc-rpm.c | 9 ++++-----
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
> > index 91778cfcbc65..da595059cafd 100644
> > --- a/drivers/interconnect/qcom/icc-rpm.c
> > +++ b/drivers/interconnect/qcom/icc-rpm.c
> > @@ -498,8 +498,7 @@ int qnoc_probe(struct platform_device *pdev)
> >
> > if (desc->has_bus_pd) {
> > ret = dev_pm_domain_attach(dev, true);
> > - if (ret)
> > - return ret;
> > + goto err_disable_clks;
>
> Hi,
> this change looks strange because we now skip the rest of the function.
>
> Is it really intended?
No, this was definitely not intentional. Thanks for catching this. I'll
send a follow up fix for Georgi to fold in or apply on top.
> Also, should dev_pm_domain_detach() be called somewhere in the error
> handling path and remove function ?
In principle, yes. (I think read the above as being another device
managed resource.)
It turns out, however, that this code is totally bogus as any power
domain would already have been attached by the platform bus code and the
above call would always just succeed. The platform code would also
handle detach on errors.
I'll send a patch to remove this.
Johan
Powered by blists - more mailing lists