From: Paul Mackerras <paulus@samba.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Greg KH <greg@kroah.com>,
Patrick Mochel <mochel@digitalimplant.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Driver Core patches for 2.6.10-rc1
Date: Thu, 11 Nov 2004 08:36:07 +1100 [thread overview]
Message-ID: <16786.35271.622222.193502@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20041110083629.A17555@flint.arm.linux.org.uk>
Russell King writes:
> On Wed, Nov 10, 2004 at 01:57:17PM +1100, Paul Mackerras wrote:
> > So we can get a driver's probe method called concurrently with its
> > bus's suspend or resume method.
>
> If correct, we probably have rather a lot of buggy drivers, because
> I certainly was not aware that this could happen. I suspect the
> average driver writer also would not be aware of that.
No doubt. I'd still like to hear from Greg or Pat about what the
concurrency rules are supposed to be, or were intended to be.
Note also that I said the *bus's* suspend/resume method. For PCI, we
have some protection since the PCI suspend/resume methods won't call
the individual pci driver's suspend/resume until pci_dev->driver is
set, which happens after the pci driver's probe routine has returned
(but of course the store to pci_dev->driver can get reordered on
some architectures since there is no barrier).
However, pci_dev->driver only gets cleared *after* the driver's remove
method returns. Thus it would be quite possible for a PCI device to
have its suspend/resume methods called while another CPU is in its
remove method.
I think that what has saved us to some extent is that we only do
suspend/resume on UP machines so far.
Regards,
Paul.
next prev parent reply other threads:[~2004-11-10 21:40 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
2004-11-10 8:36 ` Russell King
2004-11-10 21:36 ` Paul Mackerras [this message]
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=16786.35271.622222.193502@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.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®