History log of /drivers/usb/host/pci-quirks.c
Revision Date Author Comments
e6842282219e127d1ef3d6346082ab80214bbcbf 16-Apr-2012 Sarah Sharp <sarah.a.sharp@linux.intel.com> xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n

commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 upstream.

If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system
with an Intel Panther Point chipset, the PCI quirks code or the EHCI
driver will switch the ports over to the xHCI host, but the xHCI driver
will never load. The ports will be powered off and seem "dead" to the
user.

Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is
either compiled in, or compiled as a module.

This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Eric Anholt <eric.anholt@intel.com>
Reported-by: David Bein <d.bein@f5.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ce5833387ab9481e2d83939a4a36203e3461ef73 10-Feb-2012 Sarah Sharp <sarah.a.sharp@linux.intel.com> xhci: Add Lynx Point to list of Intel switchable hosts.

commit 1c12443ab8eba71a658fae4572147e56d1f84f66 upstream.

The upcoming Intel Lynx Point chipset includes an xHCI host controller
that can have ports switched from the EHCI host controller, just like
the Intel Panther Point xHCI host. This time, ports from both EHCI
hosts can be switched to the xHCI host controller. The PCI config
registers to do the port switching are in the exact same place in the
xHCI PCI configuration registers, with the same semantics.

Hooray for shipping patches for next-gen hardware before the current gen
hardware is even available for purchase!

This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
95018a53f7653e791bba1f54c8d75d9cb700d1bd 30-Mar-2012 Alex He <alex.he@amd.com> xHCI: Correct the #define XHCI_LEGACY_DISABLE_SMI

Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.

This patch should be backported to kernels as old as 2.6.31.

Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
8474ecd9231434d71a39cd1ba118629e1b036137 24-Feb-2012 Yinghai Lu <yinghai@kernel.org> PCI: Use class for quirk for usb host controller fixup

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
cab928ee1f221c9cc48d6615070fefe2e444384a 08-Feb-2012 Sarah Sharp <sarah.a.sharp@linux.intel.com> USB: Fix handoff when BIOS disables host PCI device.

On some systems with an Intel Panther Point xHCI host controller, the
BIOS disables the xHCI PCI device during boot, and switches the xHCI
ports over to EHCI. This allows the BIOS to access USB devices without
having xHCI support.

The downside is that the xHCI BIOS handoff mechanism will fail because
memory mapped I/O is not enabled for the disabled PCI device.
Jesse Barnes says this is expected behavior. The PCI core will enable
BARs before quirks run, but it will leave it in an undefined state, and
it may not have memory mapped I/O enabled.

Make the generic USB quirk handler call pci_enable_device() to re-enable
MMIO, and call pci_disable_device() once the host-specific BIOS handoff
is finished. This will balance the ref counts in the PCI core. When
the PCI probe function is called, usb_hcd_pci_probe() will call
pci_enable_device() again.

This should be back ported to kernels as old as 2.6.31. That was the
first kernel with xHCI support, and no one has complained about BIOS
handoffs failing due to memory mapped I/O being disabled on other hosts
(EHCI, UHCI, or OHCI).

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@vger.kernel.org
e4436a7c17ac2b5e138f93f83a541cba9b311685 27-Jan-2012 Jayachandran C <jayachandranc@netlogicmicro.com> usb: Skip PCI USB quirk handling for Netlogic XLP

The Netlogic XLP SoC's on-chip USB controller appears as a PCI
USB device, but does not need the EHCI/OHCI handoff done in
usb/host/pci-quirks.c.

The pci-quirks.c is enabled for all vendors and devices, and is
enabled if USB and PCI are configured.

If we do not skip the qurik handling on XLP, the readb() call in
ehci_bios_handoff() will cause a crash since byte access is not
supported for EHCI registers in XLP.

Signed-off-by: Jayachandran C <jayachandranc@netlogicmicro.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
c61875977458637226ab093a35d200f2d5789787 17-Nov-2011 Alan Stern <stern@rowland.harvard.edu> OHCI: final fix for NVIDIA problems (I hope)

Problems with NVIDIA's OHCI host controllers persist. After looking
carefully through the spec, I finally realized that when a controller
is reset it then automatically goes into a SUSPEND state in which it
is completely quiescent (no DMA and no IRQs) and from which it will
not awaken until the system puts it into the OPERATIONAL state.

Therefore there's no need to worry about controllers being in the
RESET state for extended periods, or remaining in the OPERATIONAL
state during system shutdown. The proper action for device
initialization is to put the controller into the RESET state (if it's
not there already) and then to issue a software reset. Similarly, the
proper action for device shutdown is simply to do a software reset.

This patch (as1499) implements such an approach. It simplifies
initialization and shutdown, and allows the NVIDIA shutdown-quirk code
to be removed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Arno Augustin <Arno.Augustin@web.de>
Cc: stable <stable@vger.kernel.org> [after tested in 3.2 for a while]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
97ff22ee3b4cb3a334f7385e269773141aed702f 27-Oct-2011 Alan Stern <stern@rowland.harvard.edu> USB: workaround for bug in old version of GCC

This patch (as1491) works around a bug in GCC-3.4.6, which is still
supposed to be supported. The number of microseconds in the udelay()
call in quirk_usb_disable_ehci() is fixed at 100, but the compiler
doesn't understand this and generates a link-time error. So we
replace the otherwise unused variable "delta" with a simple constant
100. This same pattern is already used in other delay loops in that
source file.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Konrad Rzepecki <krzepecki@dentonet.pl>
Tested-by: Konrad Rzepecki <krzepecki@dentonet.pl>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
f940fcd8eadfe5b909a1474b57de7755edeee62b 27-May-2011 Paul Gortmaker <paul.gortmaker@windriver.com> usb: Add export.h for EXPORT_SYMBOL/THIS_MODULE where needed

With module.h being implicitly everywhere via device.h, the absence
of explicitly including something for EXPORT_SYMBOL went unnoticed.
Since we are heading to fix things up and clean module.h from the
device.h file, we need to explicitly include these files now.

Use the lightweight version of the header that has just THIS_MODULE
and EXPORT_SYMBOL variants.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
a7e6401e19aa54924ab11ee548afaad0a55ffdc6 21-Jul-2011 Arnaud Lacombe <lacombar@gmail.com> usb/host/pci-quirks.c: correct annotation of `ehci_dmi_nohandoff_table'

ehci_bios_handoff() is marked __devinit, `ehci_dmi_nohandoff_table' should be
marked __devinitconst, not __initconst. This fixes the following section
mismatch:

WARNING: vmlinux.o(.devinit.text+0x4f08): Section mismatch in reference from the function ehci_bios_handoff() to the variable .init.rodata:ehci_dmi_nohandoff_table
The function __devinit ehci_bios_handoff() references a variable __initconst ehci_dmi_nohandoff_table.
If ehci_dmi_nohandoff_table is only used by ehci_bios_handoff then annotate ehci_dmi_nohandoff_table with a matching annotation.

Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6768458b17f9bf48a4c3a34e49b20344091b5f7e 16-Jul-2011 JiSheng Zhang <jszhang3@gmail.com> USB: xhci: fix OS want to own HC

Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC.

This patch should be backported to kernels as far back as 2.6.31.

Signed-off-by: JiSheng Zhang <jszhang3@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
6ea12a04d295235ed67010a09fdea58c949e3eb0 15-Jul-2011 Alan Stern <stern@rowland.harvard.edu> USB: OHCI: fix another regression for NVIDIA controllers

The NVIDIA series of OHCI controllers continues to be troublesome. A
few people using the MCP67 chipset have reported that even with the
most recent kernels, the OHCI controller fails to handle new
connections and spams the system log with "unable to enumerate USB
port" messages. This is different from the other problems previously
reported for NVIDIA OHCI controllers, although it is probably related.

It turns out that the MCP67 controller does not like to be kept in the
RESET state very long. After only a few seconds, it decides not to
work any more. This patch (as1479) changes the PCI initialization
quirk code so that NVIDIA controllers are switched into the SUSPEND
state after 50 ms of RESET. With no interrupts enabled and all the
downstream devices reset, and thus unable to send wakeup requests,
this should be perfectly safe (even for non-NVIDIA hardware).

The removal code in ohci-hcd hasn't been changed; it will still leave
the controller in the RESET state. As a result, if someone unloads
ohci-hcd and then reloads it, the controller won't work again until
the system is rebooted. If anybody complains about this, the removal
code can be updated similarly.

This fixes Bugzilla #22052.

Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: stable <stable@kernel.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
0c42a4e84502533ec40544324debe2a62836ae11 05-Jul-2011 Anisse Astier <anisse@astier.eu> ehci: add pci quirk for Ordissimo and RM Slate 100 too

Add another variant of the Pegatron tablet used by Ordissimo, and
apparently RM Slate 100, to the list of models that should skip the
negociation for the handoff of the EHCI controller.

Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
03c75362181b0b1d6a330e7cf8def10ba988dfbe 05-Jul-2011 Anisse Astier <anisse@astier.eu> ehci: refactor pci quirk to use standard dmi_check_system method

In commit 3610ea5397b80822e417aaa0e706fd803fb05680 (ehci: workaround for pci
quirk timeout on ExoPC), a workaround was added to skip the negociation for
the handoff of the EHCI controller.

Refactor the DMI detection code to use standard dmi_check_system function.

Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
69e848c2090aebba5698a1620604c7dccb448684 22-Feb-2011 Sarah Sharp <sarah.a.sharp@linux.intel.com> Intel xhci: Support EHCI/xHCI port switching.

The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports. These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space. The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.

This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support. By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds. (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.) Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.

This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration. We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.

Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.

Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices. It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.

Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions. We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions. Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.

The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet. I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch. I've tried to document the registers as much
as possible, so please let me know if anything is unclear.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
3610ea5397b80822e417aaa0e706fd803fb05680 12-May-2011 Andy Ross <andy.ross@windriver.com> ehci: workaround for pci quirk timeout on ExoPC

The BIOS handoff for the unused EHCI controller on the ExoPC tablet
hangs for 90 seconds on boot. Detect that device, skip negotiation
and force the handoff.

Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
5c853013dcdadb60724268bf860d372fba71694c 12-May-2011 Andy Ross <andy.ross@windriver.com> ehci: pci quirk cleanup

Factor the handoff code out from quirk_usb_disable_ehci

Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
9ab7927bb845cf2549110b19c212fe44a2bfbacb 13-Apr-2011 Joerg Roedel <joerg.roedel@amd.com> USB host: Fix lockdep warning in AMD PLL quirk

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: Joerg Roedel <joerg.roedel@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ad93562bdeecdded7d02eaaaf1aa5705ab57b1b7 01-Mar-2011 Andiry Xu <andiry.xu@amd.com> USB host: Move AMD PLL quirk to pci-quirks.c

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: Andiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
479b46b5599b1e610630d7332e168c1f9c4ee0b4 17-Feb-2011 Greg Kroah-Hartman <gregkh@suse.de> Revert "USB host: Move AMD PLL quirk to pci-quirks.c"

This reverts commit b7d5b439b7a40dd0a0202fe1c118615a3fcc3b25.
It conflicts with commit baab93afc2844b68d57b0dcca5e1d34c5d7cf411 "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: Greg Kroah-Hartman <gregkh@suse.de>
b7d5b439b7a40dd0a0202fe1c118615a3fcc3b25 25-Jan-2011 Andiry Xu <andiry.xu@amd.com> USB host: Move AMD PLL quirk to pci-quirks.c

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: Andiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
3df7169e73fc1d71a39cffeacc969f6840cdf52b 10-Sep-2010 Alan Stern <stern@rowland.harvard.edu> OHCI: work around for nVidia shutdown problem

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: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: David Brownell <david-b@pacbell.net>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
CC: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
7f26b3a7533bbc1ddd88b297c935ee4da8f74cea 04-Aug-2010 Joe Perches <joe@perches.com> drivers/usb: Remove unnecessary return's from void functions

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: Joe Perches <joe@perches.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
d93a8f829fe1d2f3002f2c6ddb553d12db420412 12-Oct-2009 Linus Torvalds <torvalds@linux-foundation.org> Revert "USB: Work around BIOS bugs by quiescing USB controllers earlier"

This reverts commit db8be50c4307dac2b37305fc59c8dc0f978d09ea, 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: Nick Piggin <npiggin@suse.de>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
db8be50c4307dac2b37305fc59c8dc0f978d09ea 03-Aug-2009 David Woodhouse <dwmw2@infradead.org> USB: Work around BIOS bugs by quiescing USB controllers earlier

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: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
132032274a594ee9ffb6b9c9e2e9698149a09ea9 03-Aug-2009 David Woodhouse <dwmw2@infradead.org> USB: Work around BIOS bugs by quiescing USB controllers earlier

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: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
66d4eadd8d067269ea8fead1a50fe87c2979a80d 28-Apr-2009 Sarah Sharp <sarah.a.sharp@linux.intel.com> USB: xhci: BIOS handoff and HW initialization.

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: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6e14bda1b18b2e3c16258427fc43ceb43e1bc1d5 31-Jan-2009 Roel Kluin <roel.kluin@gmail.com> USB: count reaches -1, tested 0

With a postfix decrement count will reach -1 rather than 0,
so the warning will not be issued.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
d859bffc662482f06ba5603e6f592de4e18cf135 05-Nov-2008 Steven Noonan <steven@uplinklabs.net> USB: EHCI pci-quirks.c: don't wait so long for BIOS handoff

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: Steven 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8e8ce4b642ce4beb865fb1d67cd8ea883d9ae7d7 21-Oct-2008 Arjan van de Ven <arjan@linux.intel.com> USB: use pci_ioremap_bar() in drivers/usb

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: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
441b62c1edb986827154768d89bbac0ba779984f 04-Mar-2008 Harvey Harrison <harvey.harrison@gmail.com> USB: replace remaining __FUNCTION__ occurrences

__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
f0fda801daaa95ad5ccf59e92e0688c34b37c627 17-Dec-2007 bjorn.helgaas@hp.com <bjorn.helgaas@hp.com> PCI: use dev_printk in quirk messages

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: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
4fe5354f61cad4c0550285283c83c66c070c198e 05-Apr-2007 Alan Stern <stern@rowland.harvard.edu> EHCI: fix problem with BIOS handoff

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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c1b45f247a2901de3982f33196d5caf8ca5b9799 26-Jun-2006 Kyle McMartin <kyle@parisc-linux.org> [PATCH] USB: Kill compiler warning in quirk_usb_handoff_ohci

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: Kyle McMartin <kyle@parisc-linux.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
6ab3d5624e172c553004ecc862bfeac16d9d68b7 30-Jun-2006 Jörn Engel <joern@wohnheim.fh-wedel.de> Remove obsolete #include <linux/config.h>

Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
75e2df603de69dba67dd64ab34a2313fdc52a4dd 25-Mar-2006 Adrian Bunk <bunk@stusta.de> [PATCH] USB: pci-quirks.c: proper prototypes

This patch adds a header file with proper prototypes for two functions
in drivers/usb/host/pci-quirks.c.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8c450802a3abf0e8a45238fcb7d22ed9d6f191ce 25-Feb-2006 David Brownell <david-b@pacbell.net> [PATCH] USB: fix EHCI BIOS handshake

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: David Brownell <dbrownell@users.sourceforge.net>
Cc: <yazar256@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
a38408cd8d6bc0e5d16e609d4b1fdf9ba2e099ce 09-Feb-2006 David Brownell <david-b@pacbell.net> [PATCH] USB: fix up the usb early handoff logic for EHCI

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: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
401feafa621ba98ecaeed5db1a53ab878943c225 24-Jan-2006 David Brownell <david-b@pacbell.net> [PATCH] USB: fix EHCI early handoff issues

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: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c9a50cc9318772e62d56f2a9172bdfda72bdacbe 08-Nov-2005 David Brownell <david-b@pacbell.net> [PATCH] USB: hcd uses EXTRA_CFLAGS for -DDEBUG

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: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
462aae65f6ea41de05ebc2a54a9e6b95563591f3 04-Nov-2005 David S. Miller <davem@davemloft.net> [USB]: Make early handoff a final fixup instead of a header one.

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: David S. Miller <davem@davemloft.net>
541ab4af11d5b41b95cd633e9b1d96cea9947ac2 01-Nov-2005 Linus Torvalds <torvalds@g5.osdl.org> Don't touch USB controller IO registers when they are disabled

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: Linus Torvalds <torvalds@osdl.org>
478a3bab8c87a9ba4a4ba338314e32bb0c378e62 19-Oct-2005 Alan Stern <stern@rowland.harvard.edu> [PATCH] USB: Always do usb-handoff

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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bb200f6eac6372839921be1fe87c1f5c292a7bd6 03-Oct-2005 Alan Stern <stern@rowland.harvard.edu> [PATCH] UHCI: unify BIOS handoff and driver reset code

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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
f2cb36c1df427431a8c6096b4ad113df767c1bd9 23-Sep-2005 David Brownell <david-b@pacbell.net> [PATCH] update PCI early-handoff handling for OHCI

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: Greg Kroah-Hartman <gregkh@suse.de>

drivers/usb/host/pci-quirks.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
7586269c0b52970f60bb69fcb86e765fc1d72309 24-Sep-2005 David Brownell <david-b@pacbell.net> [PATCH] USB: move handoff code

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: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg 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(-)