From: Paul Mackerras <paulus@samba.org>
To: Greg KH <greg@kroah.com>, Russell King <rmk+lkml@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Driver Core patches for 2.6.10-rc1
Date: Wed, 10 Nov 2004 13:57:17 +1100 [thread overview]
Message-ID: <16785.33677.704803.889900@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20041110013700.GF9496@kroah.com>
Greg KH writes:
> On Sun, Nov 07, 2004 at 03:28:05PM +0000, Russell King wrote:
> > On Tue, Nov 02, 2004 at 10:32:29PM +0000, Russell King wrote:
> > >
> > > Does this mean that a device driver can have its suspend or resume
> > > methods called in the middle of a probe or remove on a different CPU ?
> > > (note: x86 APM does not freeze all processes last time I checked...)
> > >
> > > If yes, has anyone audited the drivers to ensure that they're correct
> > > in respect of this?
> >
> > I'll repost the above question since it's of fundamental importance.
I didn't change anything that would affect that.
Unless I am misunderstanding the question, it has always been the case
that a bus's suspend or resume method could be called concurrently
with a driver probe call. device_add() calls device_pm_add() followed
by bus_add_device(). device_pm_add() puts the device on the
dpm_active list, and once it is there, device_suspend will see it, and
will call the bus's suspend function. bus_add_device() calls
device_attach() which either calls device_bind_driver() or
driver_probe_device(), and driver_probe_device() calls the driver's
probe function.
So we can get a driver's probe method called concurrently with its
bus's suspend or resume method. Whether the driver's suspend/resume
method gets called depends on the bus-specific code. In the case of
PCI, it looks like pci_device_suspend won't call the driver's suspend
function unless pci_dev->driver is set. That gets set in
pci_device_probe_{dynamic,static} after the drv->probe() call, so that
probably mostly excludes concurrency with the suspend/resume calls
(except that there is no memory barrier in there). I don't know
whether driver_probe_device() can ever get called for PCI devices. If
it can I then don't know how/where pci_dev->driver would get set (as
opposed to dev->driver).
I would stress that none of this analysis is any different before or
after my patch though. The question (of concurrency between
probe/remove and suspend/resume) is an interesting one, but it's not
something that's affected one way or the other by my patch.
Greg, do you have an analysis (or set of rules) for concurrency
between the various driver functions?
Paul.
next prev parent reply other threads:[~2004-11-10 2:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-01 21:54 [BK PATCH] " Greg KH
2004-11-01 21:57 ` [PATCH] " Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-01 21:57 ` Greg KH
2004-11-02 22:32 ` Russell King
2004-11-07 15:28 ` Russell King
2004-11-10 1:37 ` Greg KH
2004-11-10 2:57 ` Paul Mackerras [this message]
2004-11-10 8:36 ` Russell King
2004-11-10 21:36 ` Paul Mackerras
2004-11-11 0:00 ` Nigel Cunningham
2004-11-11 20:52 ` Russell King
2004-11-12 0:28 ` Greg KH
2004-11-01 23:44 ` Pozsar Balazs
-- strict thread matches above, loose matches on Subject: below --
2004-10-22 23:09 [BK PATCH] " Greg KH
2004-10-22 23:09 ` [PATCH] " Greg KH
2004-10-22 23:09 ` Greg KH
2004-10-22 23:09 ` Greg KH
2004-10-22 23:09 ` Greg KH
2004-10-22 23:09 ` Greg KH
2004-10-22 23:09 ` Greg KH
2004-10-22 23:09 ` Greg KH
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=16785.33677.704803.889900@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®