All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Kevin Hilman <khilman@ti.com>
Cc: linux-pm@lists.linux-foundation.org
Subject: Re: use of pm_runtime_disable() from driver probe?
Date: Thu, 12 Jul 2012 01:16:00 +0200	[thread overview]
Message-ID: <201207120116.00862.rjw@sisk.pl> (raw)
In-Reply-To: <87ipdthp6b.fsf@ti.com>

On Thursday, July 12, 2012, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Wednesday, July 11, 2012, Alan Stern wrote:
> >> On Wed, 11 Jul 2012, Rafael J. Wysocki wrote:
> >> 
> >> > > This opens up the possibility of calling probe while a runtime resume
> >> > > or suspend is in progress.  (On the other hand, the existing code
> >> > > doesn't prevent a concurrent runtime resume.)  Maybe it would be best
> >> > > to leave the pm_runtime_barrier().
> >> > 
> >> > That wouldn't close the race, though, because the suspend/resume may still
> >> > be started right after _barrier has returned.
> >> 
> >> True, but see below.
> >> 
> >> > The race is only possible if runtime PM is enabled by a subsystem or PM domain
> >> > code before the first eligible driver is registered and if that code is not
> >> > careful enough to get ready for driver registration.  I'm not sure how likely
> >> > it is to happen in practice.
> >> 
> >> It's not just the first eligible driver.  Drivers can be bound and 
> >> unbound dynamically, and suspends/resume operations can sit on the wait 
> >> queue or wait until a timer expires.  We don't want an old request 
> >> suddenly to take effect in the middle of a probe.
> >> 
> >> The barrier will get rid of any old requests.  New ones would have to 
> >> be added after the probe starts, which as you say, is unlikely.
> >
> > OK, I'll keep the barrier, then.
> >
> > Kevin, can you please double check the patch below?
> 
> Yup, this verion looks right and I tested it and verified that it still
> fixes the problem I'm seeing.
> 
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>

Cool, thanks!

I'll submit it officially (with a changelog and tags) tomorrow.

Rafael


> > ---
> >  drivers/base/dd.c |    6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > Index: linux/drivers/base/dd.c
> > ===================================================================
> > --- linux.orig/drivers/base/dd.c
> > +++ linux/drivers/base/dd.c
> > @@ -356,10 +356,9 @@ int driver_probe_device(struct device_dr
> >  	pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
> >  		 drv->bus->name, __func__, dev_name(dev), drv->name);
> >  
> > -	pm_runtime_get_noresume(dev);
> >  	pm_runtime_barrier(dev);
> >  	ret = really_probe(dev, drv);
> > -	pm_runtime_put_sync(dev);
> > +	pm_runtime_idle(dev);
> >  
> >  	return ret;
> >  }
> > @@ -406,9 +405,8 @@ int device_attach(struct device *dev)
> >  			ret = 0;
> >  		}
> >  	} else {
> > -		pm_runtime_get_noresume(dev);
> >  		ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
> > -		pm_runtime_put_sync(dev);
> > +		pm_runtime_idle(dev);
> >  	}
> >  out_unlock:
> >  	device_unlock(dev);
> 
> 

      reply	other threads:[~2012-07-11 23:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-06 22:29 use of pm_runtime_disable() from driver probe? Kevin Hilman
2012-07-07 19:25 ` Rafael J. Wysocki
2012-07-08  2:01   ` Alan Stern
2012-07-08 14:59     ` Rafael J. Wysocki
2012-07-10 18:11   ` Kevin Hilman
2012-07-10 18:31     ` Rafael J. Wysocki
2012-07-10 18:47       ` Alan Stern
2012-07-10 19:14         ` Rafael J. Wysocki
2012-07-10 19:41           ` Rafael J. Wysocki
2012-07-10 20:17             ` Alan Stern
2012-07-10 21:04               ` Kevin Hilman
2012-07-10 22:31               ` Rafael J. Wysocki
2012-07-11 14:20                 ` Alan Stern
2012-07-11 17:36                   ` Rafael J. Wysocki
2012-07-11 23:07                     ` Kevin Hilman
2012-07-11 23:16                       ` Rafael J. Wysocki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201207120116.00862.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=khilman@ti.com \
    --cc=linux-pm@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.