On Thu Sep 29 2005 Our Fearless Leader <[email protected]> wrote:
> > You could try adding
> >
> > ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
> >
> > near the end of ohci_pci_suspend().
>
> Give it up.
Actually the notion of doing _that_ predated that "recent" ACPI stuff,
since from time to time people with OHCI in ASICs (and without ACPI)
have said they need to run with a patch doing just that.
Which is why regardless of that other ACPI-ish issue, I'd like to
hear test results on this one. I suspect they'll be "OHCI resume
breaks for other reasons", unfortunately, but that's one reason we
have a 2.6.15 cycle upcoming. (And such reports would put a rather
different complexion on this whole recent thread too ... ;)
> 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.
The patch above would be orthogonal to that issue, though ...
If we change how usbcore does this stuff -- so hcd-pci.c won't release
and later re-allocate the IRQ -- I don't think I'd object. But I'd
rather do it in the 2.6.15 cycle, since as I understand things the
bug that restores that "ACPI braindamage" is only in the MM tree, and
there have been _no failures at all_ reported using mainstream kernels.
- Dave
> 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.
>
> Linus
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |