linux-kernel - Re: [PATCH v3 4/9] drivers: thermal: tsens: Release device in success path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHLCerM-zB=7P4Si88Hhyt8J7ojPGa6J9SmwTm8d8Jh3syiMtQ@mail.gmail.com>
Date:   Thu, 30 Jan 2020 18:19:52 +0530
From:   Amit Kucheria <amit.kucheria@...aro.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Stephen Boyd <swboyd@...omium.org>, sivaa@...eaurora.org,
        Andy Gross <agross@...nel.org>,
        Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v3 4/9] drivers: thermal: tsens: Release device in success path

On Fri, Jan 3, 2020 at 12:59 AM Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
>
> On Thu 02 Jan 06:54 PST 2020, Amit Kucheria wrote:
>
> > We don't currently call put_device in case of successfully initialising
> > the device.
> >
> > Allow control to fall through so we can use same code for success and
> > error paths to put_device.
> >
>
> Given the relationship between priv->dev and op I think this wouldn't be
> a problem in practice, but there's two devm_ioremap_resource() done on
> op->dev in this function. So you're depending on op->dev to stick
> around, but with this patch you're no longer expressing that dependency.
>
> That said, it looks iffy to do devm_ioremap_resource() on op->dev and
> then create a regmap on priv->dev using that resource. So I think it
> would be better to do platform_get_source() on op, and then
> devm_ioremap_resource() on priv->dev, in which case the regmap backing
> memory will be related to the same struct device as the regmap and it
> makes perfect sense to put_device() the op->dev when you're done
> inspecting it's resources.
>

Indeed, thanks for reviewing.

Will fix.

> > Signed-off-by: Amit Kucheria <amit.kucheria@...aro.org>
> > ---
> >  drivers/thermal/qcom/tsens-common.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/thermal/qcom/tsens-common.c b/drivers/thermal/qcom/tsens-common.c
> > index 1cbc5a6e5b4f..e84e94a6f1a7 100644
> > --- a/drivers/thermal/qcom/tsens-common.c
> > +++ b/drivers/thermal/qcom/tsens-common.c
> > @@ -687,8 +687,6 @@ int __init init_common(struct tsens_priv *priv)
> >       tsens_enable_irq(priv);
> >       tsens_debug_init(op);
> >
> > -     return 0;
> > -
> >  err_put_device:
> >       put_device(&op->dev);
> >       return ret;
> > --
> > 2.20.1
> >