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

David Brownell
2005-09-30T17:49:13Z

> Date: Fri, 30 Sep 2005 09:33:13 -0700 (PDT)
> From: Linus Torvalds <torvalds@osdl.org>
>
> 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().
>
> Btw, wouldn't this make more sense in ohci_hub_suspend()? That would pair
> up with the resume, and there seems to be nothing PCI-specific about this?
>
> There are other callers of suspend than just the PCI bus suspend.
>
> Just wondering..

Actually, no it wouldn't make sense.

Think of the OHCI driver as being in two parts: (a) downstream links,
the guts of OHCI which I'll summarize here as being the root hub;
and (b) the upstream link, a PCI or SOC bus. Both parts have their
own power management rules.

Now the OHCI controller itself supports four internal states, one of
which is called SUSPEND. It's the lowest power state that all OHCI
silicon supports. It's the state the controller enters whenever the
root hub suspends.

The OHCI driver keeps the controller in that OHCI_USB_SUSPEND state
whenever it can ... like when no devices are connected, or when all
connected devices have been suspended. At this very second, most
OHCIs running Linux are probably in this state.

And the way the controller leaves the SUSPEND state is to issue an IRQ
when someone connects a new USB device, or a suspended device (like a
USB keyboard or mouse) issues a wakeup signal.

You can see what that means. Disabling IRQs in ohci_hub_suspend()
would mean the controller couldn't wake up for new devices etc.
USB would just "not work".

It might not be appropriate to disable that in the PCI glue either;
I came across a comment from Benjamin Herrenschmidt a while back,
that some "legacy" PCI systems drive system wakeup through normal
IRQs rather than through PME#. That dovetails nicely with your
comments about disabling IRQs during suspend being ungood. :)

- Dave