Factor the handoff code out from quirk_usb_disable_ehci
Signed-off-by: NAndy Ross <andy.ross@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Booting latest kernel on my test machine produces a lockdep
warning from the usb_amd_find_chipset_info() function:

 WARNING: at /data/lemmy/linux.trees.git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x95/0xc2()
 Hardware name: Snook
 Modules linked in:
 Pid: 959, comm: work_for_cpu Not tainted 2.6.39-rc2+ #22
 Call Trace:
  [<ffffffff8103c0d4>] warn_slowpath_common+0x80/0x98
  [<ffffffff812387e6>] ? T.492+0x24/0x26
  [<ffffffff8103c101>] warn_slowpath_null+0x15/0x17
  [<ffffffff81068667>] lockdep_trace_alloc+0x95/0xc2
  [<ffffffff810ed9ac>] slab_pre_alloc_hook+0x18/0x3b
  [<ffffffff810ef227>] kmem_cache_alloc_trace+0x25/0xba
  [<ffffffff812387e6>] T.492+0x24/0x26
  [<ffffffff81238816>] pci_get_subsys+0x2e/0x73
  [<ffffffff8123886c>] pci_get_device+0x11/0x13
  [<ffffffff814082a9>] usb_amd_find_chipset_info+0x3f/0x18a
...

It turns out that this function calls pci_get_device under a spin_lock
with irqs disabled, but the pci_get_device function is only allowed in
preemptible context.

This patch fixes the warning by making all data-structure
modifications on temporal storage and commiting this back
into the visible structure at the end. While at it, this
patch also moves the pci_dev_put calls out of the spinlocks
because this function might sleep too.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.

AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:

1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.

Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:

1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
   make them cleaner;
2. AMD chipset information will be probed only once and then stored.
   Currently they're probed during every OHCI/EHCI initialization, move
   the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
   code, every host controller enable/disable PLL only according to
   its own status, and may enable PLL while there is still isoc transfer on
   other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit b7d5b439.
It conflicts with commit baab93af "USB:
EHCI: ASPM quirk of ISOC on AMD Hudson" and merging the two just doesn't
work properly.

Cc: Andiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.

AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:

1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.

Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:

1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
   make them cleaner;
2. AMD chipset information will be probed only once and then stored.
   Currently they're probed during every OHCI/EHCI initialization, move
   the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
   code, every host controller enable/disable PLL only according to
   its own status, and may enable PLL while there is still isoc transfer on
   other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1417) fixes a problem affecting some (or all) nVidia
chipsets.  When the computer is shut down, the OHCI controllers
continue to power the USB buses and evidently they drive a Reset
signal out all their ports.  This prevents attached devices from going
to low power.  Mouse LEDs stay on, for example, which is disconcerting
for users and a drain on laptop batteries.

The fix involves leaving each OHCI controller in the OPERATIONAL state
during system shutdown rather than putting it in the RESET state.
Although this nominally means the controller is running, in fact it's
not doing very much since all the schedules are all disabled.  However
there is ongoing DMA to the Host Controller Communications Area, so
the patch also disables the bus-master capability of all PCI USB
controllers after the shutdown routine runs.

The fix is applied only to nVidia-based PCI OHCI controllers, so it
shouldn't cause problems on systems using other hardware.  As an added
safety measure, in case the kernel encounters one of these running
controllers during boot, the patch changes quirk_usb_handoff_ohci()
(which runs early on during PCI discovery) to reset the controller
before anything bad can happen.
Reported-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Tested-by: NPali Rohár <pali.rohar@gmail.com>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Greg prefers this to go through the trivial tree.
http://lkml.org/lkml/2010/6/24/1

There are about 2500 void functions in drivers/usb
Only a few used return; at end of function.

Standardize them a bit.

Moved a statement down a line in drivers/usb/host/u132-hcd.c
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit db8be50c, as per

	http://bugzilla.kernel.org/show_bug.cgi?id=14374
	http://marc.info/?l=linux-kernel&m=125446885705223&w=4

We simply can't do the USB handoff at FIXUP_HEADER time, since it will
often require us to have valid IO mappings etc.  But that in turn
requires a whole different approach, not this trivial one-liner.

Maybe we could teach all the USB quirk handoff handlers to only do the
quirk if the device has all its registers set up (since if it isn't
initialized, it's unlikely to be active), but regardless that will need
a whole lot more code than just saying "let's do it really early".

The proper fix is almost certainly to just leave the legacy IOMMU
mappings active until after all devices have been initialized.
Reported-by: NNick Piggin <npiggin@suse.de>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We are seeing a number of crashes in SMM, when VT-d is enabled while
'Legacy USB support' is enabled in various BIOSes.

The BIOS is supposed to indicate which addresses it uses for DMA in a
special ACPI table ("RMRR"), so that we can punch a hole for it when we
set up the IOMMU.

The problem is, as usual, that BIOS engineers are totally incompetent.
They write code which will crash if the DMA goes AWOL, and then they
either neglect to provide an RMRR table at all, or they put the wrong
addresses in it. And of course they don't do _any_ QA, since that would
take too much time away from their crack-smoking habit.

The real fix, of course, is for consumers to refuse to buy motherboards
which only have closed-source firmware available. If we had _open_
firmware, bugs like this would be easy to fix.

Since that's something I can only dream about, this patch implements an
alternative -- ensuring that the USB controllers are handed off from the
BIOS and quiesced _before_ the IOMMU is initialised. That would have
been a much better design than this RMRR nonsense in the first place, of
course. The bootloader has no business doing DMA after the OS has booted
anyway.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We are seeing a number of crashes in SMM, when VT-d is enabled while
'Legacy USB support' is enabled in various BIOSes.

The BIOS is supposed to indicate which addresses it uses for DMA in a
special ACPI table ("RMRR"), so that we can punch a hole for it when we
set up the IOMMU.

The problem is, as usual, that BIOS engineers are totally incompetent.
They write code which will crash if the DMA goes AWOL, and then they
either neglect to provide an RMRR table at all, or they put the wrong
addresses in it. And of course they don't do _any_ QA, since that would
take too much time away from their crack-smoking habit.

The real fix, of course, is for consumers to refuse to buy motherboards
which only have closed-source firmware available. If we had _open_
firmware, bugs like this would be easy to fix.

Since that's something I can only dream about, this patch implements an
alternative -- ensuring that the USB controllers are handed off from the
BIOS and quiesced _before_ the IOMMU is initialised. That would have
been a much better design than this RMRR nonsense in the first place, of
course. The bootloader has no business doing DMA after the OS has booted
anyway.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add PCI initialization code to take control of the xHCI host controller
away from the BIOS, halt, and reset the host controller.  The xHCI spec
says that BIOSes must give up the host controller within 5 seconds.

Add some host controller glue functions to handle hardware initialization
and memory allocation for the host controller.  The current xHCI
prototypes use PCI interrupts, but the xHCI spec requires MSI-X
interrupts.  Add code to support MSI-X interrupts, but use the PCI
interrupts for now.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

With a postfix decrement count will reach -1 rather than 0,
so the warning will not be issued.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Instead of waiting a painful 5000ms, quirk_usb_disable_ehci() now does a
1000ms loop to wait for the BIOS to acknowledge the handoff.

The five second delay is really quite irritating to have to deal with
every boot up, and I very seriously doubt any non-broken bios takes more
than a second to do the actual handoff.
Signed-off-by: NSteven Noonan <steven@uplinklabs.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Use the newly introduced pci_ioremap_bar() function in drivers/usb.
pci_ioremap_bar() just takes a pci device and a bar number, with the goal
of making it really hard to get wrong, while also having a central place
to stick sanity checks.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Convert quirk printks to dev_printk().

I made the MSI disable messages a little more consistent:

    - always use "disabled", not "deactivated"
    - specify "device MSI disabled" or "subordinate MSI disabled" when
      disabling MSI for only a specific device or subordinate bus
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as882) fixes a problem with the EHCI BIOS handoff.  On my
machine, the BIOS configures the controller and the handoff fails,
leaving the controller configured.  During resume-from-disk, this
confuses ehci-hcd into thinking that the controller has not been
tampered with.

The problem is fixed by turning off the Configured Flag whenever a
BIOS handoff is attempted, whether it succeeds or not.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Move variables only used on !__hppa__ into that #ifndef section. This
cleans up a compiler warning on parisc. Problem pointed out by
Joel Soete.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

This patch adds a header file with proper prototypes for two functions
in drivers/usb/host/pci-quirks.c.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix http://bugzilla.kernel.org/show_bug.cgi?id=6128

Finish morphing the "early handoff" version of the EHCI BIOS handshake over
to match the previous implementation inside the EHCI driver (except that
now we forcibly disable the SMI).  The version that had been with the PCI
code was surprisingly full of bugs.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: <yazar256@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Disable some dubious "early" USB handoff code that allegedly works around bugs
on some systems (we don't know which ones) but rudely breaks some others.

Also make the kernel warnings reporting BIOS handoff problems be more useful,
reporting the register whose value displays the trouble.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This moves the previously widely-used ehci-pci.c BIOS handoff
code into the pci-quirks.c file, replacing the less widely used
"early handoff" version that seems to cause problems lately.

One notable change:  the "early handoff" version always enabled
an SMI IRQ ... and did so even if the pre-Linux code said it was
not using EHCI (and not expecting EHCI SMIs).  Looks like a goof
in a workaround for some unknown BIOS version.

This merged version only forcibly enables those IRQs when pre-Linux
code says it's using EHCI.  And now it always forces them off "just
in case".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This modifies the HCD builds to automatically "-DDEBUG" if
CONFIG_USB_DEBUG is selected.  It's just a minor source code cleanup,
guaranteeing consistency.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

At header fixup time, it is not yet legal to ioremap() PCI
device registers, yet that is what this quirk code needs to
do.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The USB "handoff" code is an early PCI quirk to make sure we own the USB
controller (as opposed to the BIOS/SMM).  But if the controller isn't
even enabled yet, don't try to access it.

Acked-by: Paul Mackerras <paulus@samba.org> (who had an alternate patch)
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This revised patch (as586b) makes usb-handoff permanently true and no
longer a kernel boot parameter.  It also removes the piix3_usb quirk code;
that was nothing more than an early version of the USB handoff code
(written at a time when Intel's PIIX3 was about the only motherboard with
USB support).  And it adds identifiers for the three PCI USB controller
classes to pci_ids.h.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as574) updates the PCI BIOS usb-handoff code for UHCI
controllers, making it work like the reset routines in uhci-hcd.  This
allows uhci-hcd to drop its own routines in favor of the new ones
(code-sharing).

Once the patch is merged we can turn the usb-handoff option on
permanently, as far as UHCI is concerned.  OHCI and EHCI may still have
some issues.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The PCI "early usb handoff" quirk logic didn't work like "ohci-hcd" ...
This patch makes it do so by:

  - Resetting the controller after kicking BIOS off, matching the
    normal "chip in hardware reset" startup mode;

  - Reporting any BIOS that borks this simple handoff; it's likely
    got a few other surprises for us too.

  - Ignoring that handoff on HPPA;

The diagnostic string is mostly shared with EHCI, saving a few bytes.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

 drivers/usb/host/pci-quirks.c |   22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory.  Follow-on patches will need to:

(a) merge these copies with the originals in the HCD reset methods.
they don't wholly agree, despite doing the very same thing; and

(b) eventually change it so "usb-handoff" is the default, to help
get more robust USB/BIOS/input/... interactions.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

 drivers/Makefile              |    2
 drivers/pci/quirks.c          |  253 ---------------------------------------
 drivers/usb/Makefile          |    1
 drivers/usb/host/Makefile     |    5
 drivers/usb/host/pci-quirks.c |  272 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 280 insertions(+), 253 deletions(-)