Re: [linux-usb-devel] Re: 2.6.13-mm2

David Brownell
2005-09-29T16:32:04Z

On Thu Sep 29 2005 Our Fearless Leader <torvalds@osdl.org> 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
>