summaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/pci-quirks.c
AgeCommit message (Collapse)Author
2013-01-24usb: Prevent dead ports when xhci is not enabledDavid Moore
When the xHCI driver is not available, actively switch the ports to EHCI mode since some BIOSes leave them in xHCI mode where they would otherwise appear dead. This was discovered on a Dell Optiplex 7010, but it's possible other systems could be affected. This should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: David Moore <david.moore@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-11-28xhci: Add Lynx Point LP to list of Intel switchable hostsRussell Webb
Like Lynx Point, Lynx Point LP is also switchable. See 1c12443ab8eba71a658fae4572147e56d1f84f66 for more details. 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: Russell Webb <russell.webb@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-11-21usb: remove use of __devinitconstBill Pemberton
CONFIG_HOTPLUG is going away as an option so __devinitconst is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Li Yang <leoli@freescale.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-21usb: remove use of __devinitBill Pemberton
CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Peter Korsgaard <jacmet@sunsite.dk> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Acked-by: Felipe Balbi <balbi@ti.com> Cc: Li Yang <leoli@freescale.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Geoff Levand <geoff@infradead.org> Cc: Wan ZongShun <mcuos.com@gmail.com> Cc: Olav Kongas <ok@artecdesign.ee> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-25ehci: Add yet-another Lucid nohandoff pci quirkAnisse Astier
Board name changed on another shipping Lucid tablet. Signed-off-by: Anisse Astier <anisse@astier.eu> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-25ehci: fix Lucid nohandoff pci quirk to be more generic with BIOS versionsAnisse Astier
BIOS vendors keep changing the BIOS versions. Only match the beginning of the string to match all Lucid tablets with board name M11JB. Signed-off-by: Anisse Astier <anisse@astier.eu> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-05xhci: Make handover code more robustMatthew Garrett
My test platform (Intel DX79SI) boots reliably under BIOS, but frequently crashes when booting via UEFI. I finally tracked this down to the xhci handoff code. It seems that reads from the device occasionally just return 0xff, resulting in xhci_find_next_cap_offset generating a value that's larger than the resource region. We then oops when attempting to read the value. Sanity checking that value lets us avoid the crash. I've no idea what's causing the underlying problem, and xhci still doesn't actually *work* even with this, but the machine at least boots which will probably make further debugging easier. This should be backported to kernels as old as 2.6.31, that contain the commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff and HW initialization." Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-04Intel xhci: Only switch the switchable portsKeng-Yu Lin
With a previous patch to enable the EHCI/XHCI port switching, it switches all the available ports. The assumption is not correct because the BIOS may expect some ports not switchable by the OS. There are two more registers that contains the information of the switchable and non-switchable ports. This patch adds the checking code for the two register so that only the switchable ports are altered. This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Keng-Yu Lin <kengyu@canonical.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-04xhci: Recognize USB 3.0 devices as superspeed at powerupManoj Iyer
On Intel Panther Point chipset USB 3.0 devices show up as high-speed devices on powerup, but after an s3 cycle they are correctly recognized as SuperSpeed. At powerup switch the port to xHCI so that USB 3.0 devices are correctly recognized. BugLink: http://bugs.launchpad.net/bugs/1000424 This patch should be backported to kernels as old as 3.0, that contain commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-08-09xhci: Switch PPT ports to EHCI on shutdown.Sarah Sharp
The Intel desktop boards DH77EB and DH77DF have a hardware issue that can be worked around by BIOS. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS will work around this, but not all. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. The Intel Windows driver switches the ports back to EHCI, so change the Linux xHCI driver to do the same. Unfortunately, we can't tell the two effected boards apart from other working motherboards, because the vendors will change the DMI strings for the DH77EB and DH77DF boards to their own custom names. One example is Compulab's mini-desktop, the Intense-PC. Instead, key off the Panther Point xHCI host PCI vendor and device ID, and switch the ports over for all PPT xHCI hosts. The only impact this will have on non-effected boards is to add a couple hundred milliseconds delay on boot when the BIOS has to switch the ports over from EHCI to xHCI. This patch should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Denis Turischev <denis@compulab.co.il> Tested-by: Denis Turischev <denis@compulab.co.il> Cc: stable@vger.kernel.org
2012-05-03xhci: Add Lynx Point to list of Intel switchable hosts.Sarah Sharp
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> Cc: stable@vger.kernel.org
2012-05-03xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=nSarah Sharp
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> Cc: stable@vger.kernel.org
2012-04-11xHCI: Correct the #define XHCI_LEGACY_DISABLE_SMIAlex He
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
2012-03-23Merge branch 'linux-next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci Pull PCI changes (including maintainer change) from Jesse Barnes: "This pull has some good cleanups from Bjorn and Yinghai, as well as some more code from Yinghai to better handle resource re-allocation when enabled. There's also a new initcall_debug feature from Arjan which will print out quirk timing information to help identify slow quirks for fixing or refinement (Yinghai sent in a few patches to do just that once the new debug code landed). Beyond that, I'm handing off PCI maintainership to Bjorn Helgaas. He's been a core PCI and Linux contributor for some time now, and has kindly volunteered to take over. I just don't feel I have the time for PCI review and work that it deserves lately (I've taken on some other projects), and haven't been as responsive lately as I'd like, so I approached Bjorn asking if he'd like to manage things. He's going to give it a try, and I'm confident he'll do at least as well as I have in keeping the tree managed, patches flowing, and keeping things stable." Fix up some fairly trivial conflicts due to other cleanups (mips device resource fixup cleanups clashing with list handling cleanup, ppc iseries removal clashing with pci_probe_only cleanup etc) * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci: (112 commits) PCI: Bjorn gets PCI hotplug too PCI: hand PCI maintenance over to Bjorn Helgaas unicore32/PCI: move <asm-generic/pci-bridge.h> include to asm/pci.h sparc/PCI: convert devtree and arch-probed bus addresses to resource powerpc/PCI: allow reallocation on PA Semi powerpc/PCI: convert devtree bus addresses to resource powerpc/PCI: compute I/O space bus-to-resource offset consistently arm/PCI: don't export pci_flags PCI: fix bridge I/O window bus-to-resource conversion x86/PCI: add spinlock held check to 'pcibios_fwaddrmap_lookup()' PCI / PCIe: Introduce command line option to disable ARI PCI: make acpihp use __pci_remove_bus_device instead PCI: export __pci_remove_bus_device PCI: Rename pci_remove_behind_bridge to pci_stop_and_remove_behind_bridge PCI: Rename pci_remove_bus_device to pci_stop_and_remove_bus_device PCI: print out PCI device info along with duration PCI: Move "pci reassigndev resource alignment" out of quirks.c PCI: Use class for quirk for usb host controller fixup PCI: Use class for quirk for ti816x class fixup PCI: Use class for quirk for intel e100 interrupt fixup ...
2012-02-24PCI: Use class for quirk for usb host controller fixupYinghai Lu
Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2012-02-21USB: Fix handoff when BIOS disables host PCI device.Sarah Sharp
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
2012-02-02usb: Skip PCI USB quirk handling for Netlogic XLPJayachandran C
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>
2011-11-18OHCI: final fix for NVIDIA problems (I hope)Alan Stern
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>
2011-11-14USB: workaround for bug in old version of GCCAlan Stern
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>
2011-10-31usb: Add export.h for EXPORT_SYMBOL/THIS_MODULE where neededPaul Gortmaker
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>
2011-08-08usb/host/pci-quirks.c: correct annotation of `ehci_dmi_nohandoff_table'Arnaud Lacombe
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>
2011-08-01USB: xhci: fix OS want to own HCJiSheng Zhang
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
2011-07-16USB: OHCI: fix another regression for NVIDIA controllersAlan Stern
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>
2011-07-08ehci: add pci quirk for Ordissimo and RM Slate 100 tooAnisse Astier
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>
2011-07-08ehci: refactor pci quirk to use standard dmi_check_system methodAnisse Astier
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>
2011-05-27Intel xhci: Support EHCI/xHCI port switching.Sarah Sharp
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>
2011-05-12ehci: workaround for pci quirk timeout on ExoPCAndy Ross
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>
2011-05-12ehci: pci quirk cleanupAndy Ross
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>
2011-04-13USB host: Fix lockdep warning in AMD PLL quirkJoerg Roedel
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>
2011-03-01USB host: Move AMD PLL quirk to pci-quirks.cAndiry Xu
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>
2011-02-17Revert "USB host: Move AMD PLL quirk to pci-quirks.c"Greg Kroah-Hartman
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>
2011-02-04USB host: Move AMD PLL quirk to pci-quirks.cAndiry Xu
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>
2010-10-24Merge branch 'for-next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits) Update broken web addresses in arch directory. Update broken web addresses in the kernel. Revert "drivers/usb: Remove unnecessary return's from void functions" for musb gadget Revert "Fix typo: configuation => configuration" partially ida: document IDA_BITMAP_LONGS calculation ext2: fix a typo on comment in ext2/inode.c drivers/scsi: Remove unnecessary casts of private_data drivers/s390: Remove unnecessary casts of private_data net/sunrpc/rpc_pipe.c: Remove unnecessary casts of private_data drivers/infiniband: Remove unnecessary casts of private_data drivers/gpu/drm: Remove unnecessary casts of private_data kernel/pm_qos_params.c: Remove unnecessary casts of private_data fs/ecryptfs: Remove unnecessary casts of private_data fs/seq_file.c: Remove unnecessary casts of private_data arm: uengine.c: remove C99 comments arm: scoop.c: remove C99 comments Fix typo configue => configure in comments Fix typo: configuation => configuration Fix typo interrest[ing|ed] => interest[ing|ed] Fix various typos of valid in comments ... Fix up trivial conflicts in: drivers/char/ipmi/ipmi_si_intf.c drivers/usb/gadget/rndis.c net/irda/irnet/irnet_ppp.c
2010-10-22OHCI: work around for nVidia shutdown problemAlan Stern
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>
2010-08-10drivers/usb: Remove unnecessary return's from void functionsJoe Perches
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>
2009-10-11Revert "USB: Work around BIOS bugs by quiescing USB controllers earlier"Linus Torvalds
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>
2009-09-23USB: Work around BIOS bugs by quiescing USB controllers earlierDavid Woodhouse
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>
2009-06-15USB: xhci: BIOS handoff and HW initialization.Sarah Sharp
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>
2009-03-24USB: count reaches -1, tested 0Roel Kluin
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>
2009-01-07USB: EHCI pci-quirks.c: don't wait so long for BIOS handoffSteven Noonan
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>
2009-01-07USB: use pci_ioremap_bar() in drivers/usbArjan van de Ven
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>
2008-04-24USB: replace remaining __FUNCTION__ occurrencesHarvey Harrison
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-02-01PCI: use dev_printk in quirk messagesbjorn.helgaas@hp.com
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>
2007-05-22EHCI: fix problem with BIOS handoffAlan Stern
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>
2006-07-12[PATCH] USB: Kill compiler warning in quirk_usb_handoff_ohciKyle McMartin
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>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-04-14[PATCH] USB: pci-quirks.c: proper prototypesAdrian Bunk
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>
2006-02-28[PATCH] USB: fix EHCI BIOS handshakeDavid Brownell
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>
2006-02-13[PATCH] USB: fix up the usb early handoff logic for EHCIDavid Brownell
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>
2006-01-31[PATCH] USB: fix EHCI early handoff issuesDavid Brownell
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>