lkml.org 
[lkml]   [2020]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Re: Re: [PATCH] spi: tegra20-slink: Fix runtime PM imbalance on error
> On Fri, May 22, 2020 at 6:20 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Fri, May 22, 2020 at 10:46 AM <dinghao.liu@zju.edu.cn> wrote:
>
> ...
>
> > Moreover, consider below case
> >
> > CPU1: ...somewhere in the code...
> > pm_runtime_get() // with success!
> > ...see below...
> > pm_runtime_put()
> >
> > CPU2: ...on parallel thread...
> > ret = pm_runtime_get_sync() // failed!
> > if (ret)
> > pm_runtime_put() // oi vei, we put device into sleep
> >
> > So, there is a potential issue.
>
> ...and even if it's impossible (no bugs in runtime PM core, etc) the
> code with put() looks suspicious.
>

I may understand what you are worried about. Do you mean that
executing pm_runtime_put() will influence other threads (e.g.,
one parallel thread can put the device into sleep while other
threads are using this device)?

I think this will never happen. Because in this case the PM usage
counter cannot be decreased to zero if there are still some threads
using this device. Otherwise, pm_runtime_put() should never be
used in the case of multithreading, which is strange since this
API is used widely.

I also checked many other implementation of probe in drivers.
It seems that using pm_runtime_put() is ok. If I misunderstood
your opinion, please point it out, thanks.

Regards,
Dinghao

> --
> With Best Regards,
> Andy Shevchenko
\
 
 \ /
  Last update: 2020-05-23 13:34    [W:0.043 / U:3.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site