linux-kernel - Re: [PATCH v2 2/5] media: i2c: ov5645: Use runtime PM

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: <CA+V-a8vQkvO5k=b169SfiD5qdn9hNOJk6y2GHns1OkrnxHXeXQ@mail.gmail.com>
Date:   Mon, 31 Oct 2022 16:10:45 +0000
From:   "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To:     Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        Shawn Tu <shawnx.tu@...el.com>,
        Jacopo Mondi <jacopo@...ndi.org>, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org,
        Biju Das <biju.das.jz@...renesas.com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v2 2/5] media: i2c: ov5645: Use runtime PM

Hi Sakari,

On Mon, Oct 31, 2022 at 2:25 PM Sakari Ailus
<sakari.ailus@...ux.intel.com> wrote:
>
> Hi Prabhakar,
>
> On Thu, Oct 27, 2022 at 06:37:58PM +0000, Sakari Ailus wrote:
> > Hi Prabhakar,
> >
> > On Thu, Oct 27, 2022 at 05:32:07PM +0100, Lad, Prabhakar wrote:
> > > Hi Sakari,
> > >
> > > On Thu, Oct 27, 2022 at 1:47 PM Sakari Ailus
> > > <sakari.ailus@...ux.intel.com> wrote:
> > > >
> > > > Hi Prabhakar,
> > > >
> > > > On Thu, Oct 27, 2022 at 01:01:52PM +0100, Lad, Prabhakar wrote:
> > > > > Hi Sakari,
> > > > >
> > > > > On Thu, Oct 27, 2022 at 12:20 PM Sakari Ailus
> > > > > <sakari.ailus@...ux.intel.com> wrote:
> > > > > >
> > > > > > Hi Prabhakar,
> > > > > >
> > > > > > One more comment.
> > > > > >
> > > > > > On Fri, Oct 14, 2022 at 07:34:56PM +0100, Prabhakar wrote:
> > > > > > > @@ -1209,12 +1190,16 @@ static int ov5645_probe(struct i2c_client *client)
> > > > > > >
> > > > > > >       dev_info(dev, "OV5645 detected at address 0x%02x\n", client->addr);
> > > > > > >
> > > > > > > +     pm_runtime_set_active(dev);
> > > > > > > +     pm_runtime_get_noresume(dev);
> > > > > > > +     pm_runtime_enable(dev);
> > > > > >
> > > > > > You won't gain anything by eanbling runtime PM here. Just move it to the
> > > > > > end of the function before the rest of the calls. Error handling becomes
> > > > > > more simple.
> > > > > >
> > > > > If I move the above calls below I get the below warning:
> > > > >
> > > > > [    2.633386] ov5645 0-003c: Runtime PM usage count underflow!
> > > > >
> > > > > This is because of the last patch which moves ov5645_entity_init_cfg()
> > > > > before registering the subdev. ov5645_entity_init_cfg() calls s_ctrl
> > > > > due to which we are seeing the above message. Please let me know how
> > > > > to proceed on this.
> > > >
> > > > Ah. Yes, this is a problem with the usage pattern of
> > > > pm_runtime_get_if_in_use(). But please don't change that.
> > > >
> > > > You can still move enabling runtime PM later in the function.
> > > >
> > > Agreed, the final version looks like below:
> > >
> > >     pm_runtime_set_active(dev);
> > >     pm_runtime_get_noresume(dev);
> > >
> >
> > You'll have to enable runtime PM here, before pm_runtime_get_if_in_use()
> > gets called.
> >
> > I'll see if it could be made to work in a sensible way when runtime PM
> > isn't enabled yet.
>
> There are various ways how runtime PM interface functions generally work,
> and generally return an error when runtime PM is disabled. Incrementing the
> usage_count when runtime PM is disabled would make
> pm_runtime_get_if_in_use() very special and not match what the rest would
> do. Therefore I think it's best to keep this in the driver. After all, mo
> other driver needs this in the media tree, which is the major user of the
> function.
>
Thank you for digging deep into this. I'll keep it as is and send a v3.

Cheers,
Prabhakar