From: Daniel Ritz <daniel.ritz@gmx.ch>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Brownell <david-b@pacbell.net>,
rjw@sisk.pl, linux-usb-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, hugh@veritas.com, akpm@osdl.org
Subject: Re: [linux-usb-devel] Re: 2.6.13-mm2
Date: Thu, 29 Sep 2005 21:39:32 +0200 [thread overview]
Message-ID: <200509292139.33225.daniel.ritz@gmx.ch> (raw)
In-Reply-To: <Pine.LNX.4.58.0509290832190.3308@g5.osdl.org>
On Thursday 29 September 2005 17.36, Linus Torvalds wrote:
>
> On Wed, 28 Sep 2005, David Brownell wrote:
> >
> > You could try adding
> >
> > ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
> >
> > near the end of ohci_pci_suspend().
that's what i meant with "i think ohci-hcd does not fully disable
interrupts in it's suspend callback"...
>
> Give it up.
i'd say: yes put that line there to shut up the controller during suspend
and nuke the free_irq() in suspend to avoid problems during restore (attached).
>
> The right thing is to not free and re-aquire the damn interrupt in the
> first place. It was a MISTAKE. We undid the ACPI braindamage that made it
> be required a month ago, because sane people REALIZED it was a mistake.
>
> It's not just "random luck" that not releasing the interrupt over suspend
> fixes the problem. The problem is _due_ to drivers releasing the
> interrupt in the first place.
>
> IT DOESN'T MATTER what we do before the suspend, because we don't control
> the wakeup sequence. If the BIOS wakeup enables the devices again, the
> fact that we disabled them on suspend makes zero difference.
>
> And yes, we can always "fix" things by selecting the right order to
> re-aquire the interrupts, but the thing is, the "right order" will be
> machine-dependent and in general depend on the phase of the moon and BIOS
> version, and ACPI quirks.
>
> The _only_ sane thing to do is to not drop the interrupts in the first
> place. So that if you start getting interrupts before you expect them, you
> can still handle them.
>
fully agreed.
> Linus
>
attached the patch that kills the free_irq()/request_irq() pair in USB.
one round in -mm?
rgds
-daniel
----
[PATCH] usb/core/hcd-pci.c: don't free_irq() on suspend
the free_irq() in USB suspend breaks resume on some setups where USB
(ohci/ehci) shares the interrupt with an other device.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -242,7 +242,6 @@ int usb_hcd_pci_suspend (struct pci_dev
case HC_STATE_SUSPENDED:
/* no DMA or IRQs except when HC is active */
if (dev->current_state == PCI_D0) {
- free_irq (hcd->irq, hcd);
pci_save_state (dev);
pci_disable_device (dev);
}
@@ -374,14 +373,6 @@ int usb_hcd_pci_resume (struct pci_dev *
hcd->state = HC_STATE_RESUMING;
hcd->saw_irq = 0;
- retval = request_irq (dev->irq, usb_hcd_irq, SA_SHIRQ,
- hcd->irq_descr, hcd);
- if (retval < 0) {
- dev_err (hcd->self.controller,
- "can't restore IRQ after resume!\n");
- usb_hc_died (hcd);
- return retval;
- }
retval = hcd->driver->resume (hcd);
if (!HC_IS_RUNNING (hcd->state)) {
next prev parent reply other threads:[~2005-09-29 19:39 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-08 12:30 2.6.13-mm2 Andrew Morton
2005-09-08 13:12 ` 2.6.13-mm2 Benoit Boissinot
2005-09-08 13:48 ` 2.6.13-mm2 Christoph Hellwig
2005-09-08 14:30 ` 2.6.13-mm2 Martin J. Bligh
2005-09-09 0:39 ` 2.6.13-mm2 Andi Kleen
2005-09-09 10:41 ` 2.6.13-mm2 Andrew Morton
2005-09-09 10:46 ` 2.6.13-mm2 Andi Kleen
2005-09-08 15:11 ` 2.6.13-mm2 high memory support borken? Michal Piotrowski
2005-09-09 9:29 ` Andrew Morton
2005-09-08 17:20 ` 2.6.13-mm2 Michael Thonke
2005-09-08 19:39 ` 2.6.13-mm2 Andrew Morton
2005-09-10 7:02 ` 2.6.13-mm2 Michael Thonke
2005-09-09 1:47 ` 2.6.13-mm2 Grant Coady
2005-09-09 9:43 ` 2.6.13-mm2 Andrew Morton
2005-09-09 13:45 ` 2.6.13-mm2 Grant Coady
2005-09-10 6:33 ` 2.6.13-mm2 Marko Kohtala
2005-09-09 2:52 ` 2.6.13-mm2 - drivers/char/speakup/speakup doesn't compile (+warnings from other things) Damir Perisa
2005-09-09 12:18 ` Alan Cox
2005-09-09 20:57 ` 2.6.13-mm2 (general protection fault) Dominik Karall
2005-09-10 11:45 ` 2.6.13-mm2 Manuel Lauss
2005-09-10 12:42 ` 2.6.13-mm2 Antonino A. Daplas
2005-09-10 13:46 ` 2.6.13-mm2 Manuel Lauss
2005-09-10 20:21 ` 2.6.13-mm2 Antonino A. Daplas
2005-09-10 21:26 ` 2.6.13-mm2 Antonino A. Daplas
2005-09-10 18:43 ` 2.6.13-mm2 Dominik Karall
2005-09-10 22:12 ` 2.6.13-mm2 Andrew Morton
2005-09-10 23:46 ` 2.6.13-mm2 J.A. Magallon
2005-09-10 23:56 ` 2.6.13-mm2 Andrew Morton
2005-09-11 0:07 ` 2.6.13-mm2 Patrick McHardy
2005-09-11 0:49 ` 2.6.13-mm2 J.A. Magallon
2005-09-11 0:58 ` 2.6.13-mm2 J.A. Magallon
2005-09-11 1:03 ` 2.6.13-mm2 Patrick McHardy
2005-09-11 1:22 ` 2.6.13-mm2 J.A. Magallon
2005-09-11 1:25 ` 2.6.13-mm2 Patrick McHardy
2005-09-11 17:03 ` 2.6.13-mm2 Rafael J. Wysocki
2005-09-11 19:36 ` 2.6.13-mm2 Andrew Morton
2005-09-11 20:03 ` 2.6.13-mm2 Hugh Dickins
2005-09-12 19:19 ` 2.6.13-mm2 Rafael J. Wysocki
2005-09-11 20:08 ` 2.6.13-mm2 Daniel Ritz
2005-09-12 10:04 ` 2.6.13-mm2 Rafael J. Wysocki
2005-09-12 10:06 ` 2.6.13-mm2 Rafael J. Wysocki
2005-09-12 10:09 ` 2.6.13-mm2 Rafael J. Wysocki
2005-09-18 21:49 ` 2.6.13-mm2 Daniel Ritz
2005-09-19 3:07 ` 2.6.13-mm2 Hugh Dickins
2005-09-19 15:56 ` 2.6.13-mm2 Daniel Ritz
2005-09-23 16:52 ` 2.6.13-mm2 Rafael J. Wysocki
2005-09-28 20:05 ` 2.6.13-mm2 Daniel Ritz
2005-09-28 20:23 ` [linux-usb-devel] 2.6.13-mm2 David Brownell
2005-09-28 20:37 ` Rafael J. Wysocki
2005-09-28 20:56 ` David Brownell
2005-09-28 21:34 ` Rafael J. Wysocki
2005-09-28 22:04 ` David Brownell
2005-09-28 22:32 ` Daniel Ritz
2005-09-29 0:09 ` David Brownell
2005-09-29 15:36 ` Linus Torvalds
2005-09-29 16:31 ` David Brownell
2005-09-29 19:39 ` Daniel Ritz [this message]
2005-09-30 16:33 ` Linus Torvalds
2005-09-30 17:48 ` David Brownell
2005-09-29 2:54 ` Alan Stern
2005-09-28 20:45 ` Daniel Ritz
2005-09-28 21:07 ` David Brownell
2005-09-28 21:47 ` Rafael J. Wysocki
2005-09-28 22:07 ` Daniel Ritz
2005-09-28 21:10 ` Alan Stern
2005-09-29 15:22 ` 2.6.13-mm2 Linus Torvalds
2005-09-12 3:07 ` 2.6.13-mm2 Martin J. Bligh
2005-09-12 5:01 ` 2.6.13-mm2 Andi Kleen
2005-09-12 6:09 ` 2.6.13-mm2 Martin J. Bligh
2005-09-12 7:16 ` 2.6.13-mm2 Andi Kleen
2005-09-12 18:06 ` 2.6.13-mm2 Martin J. Bligh
2005-09-12 18:19 ` 2.6.13-mm2 Dave Hansen
2005-09-12 18:51 ` 2.6.13-mm2 Andi Kleen
2005-09-12 22:46 ` 2.6.13-mm2 Martin J. Bligh
2005-09-13 0:08 ` 2.6.13-mm2 Andrew Morton
2005-09-13 4:00 ` 2.6.13-mm2 Martin J. Bligh
2005-09-12 3:10 ` 2.6.13-mm2 Martin J. Bligh
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=200509292139.33225.daniel.ritz@gmx.ch \
--to=daniel.ritz@gmx.ch \
--cc=akpm@osdl.org \
--cc=david-b@pacbell.net \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=rjw@sisk.pl \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox