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 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.