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

[David Brownell <david-b@pacbell.net>]

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
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/