aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci/quirks.c
Commit message (Collapse)AuthorAgeFilesLines
* ahci: Add AMD CZ SATA device IDShane Huang2013-07-211-0/+2
| | | | | | | | | | | | | commit fafe5c3d82a470d73de53e6b08eb4e28d974d895 upstream. To add AMD CZ SATA controller device ID of IDE mode. [bhelgaas: drop pci_ids.h update] Signed-off-by: Shane Huang <shane.huang@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHzAndy Lutomirski2013-01-111-2/+5
| | | | | | | | | | | | | | | | | | | | | commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream. Otherwise it fails like this on cards like the Transcend 16GB SDHC card: mmc0: new SDHC card at address b368 mmcblk0: mmc0:b368 SDC 15.0 GiB mmcblk0: error -110 sending status command, retrying mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0 Tested on my Lenovo x200 laptop. [bhelgaas: changelog] Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Chris Ball <cjb@laptop.org> CC: Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PCI: EHCI: fix crash during suspend on ASUS computersAlan Stern2012-07-161-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream. Quite a few ASUS computers experience a nasty problem, related to the EHCI controllers, when going into system suspend. It was observed that the problem didn't occur if the controllers were not put into the D3 power state before starting the suspend, and commit 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during suspend on ASUS computers) was created to do this. It turned out this approach messed up other computers that didn't have the problem -- it prevented USB wakeup from working. Consequently commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it reverted the earlier commit and added a whitelist of known good board names. Now we know the actual cause of the problem. Thanks to AceLan Kao for tracking it down. According to him, an engineer at ASUS explained that some of their BIOSes contain a bug that was added in an attempt to work around a problem in early versions of Windows. When the computer goes into S3 suspend, the BIOS tries to verify that the EHCI controllers were first quiesced by the OS. Nothing's wrong with this, but the BIOS does it by checking that the PCI COMMAND registers contain 0 without checking the controllers' power state. If the register isn't 0, the BIOS assumes the controller needs to be quiesced and tries to do so. This involves making various MMIO accesses to the controller, which don't work very well if the controller is already in D3. The end result is a system hang or memory corruption. Since the value in the PCI COMMAND register doesn't matter once the controller has been suspended, and since the value will be restored anyway when the controller is resumed, we can work around the BIOS bug simply by setting the register to 0 during system suspend. This patch (as1590) does so and also reverts the second commit mentioned above, which is now unnecessary. In theory we could do this for every PCI device. However to avoid introducing new problems, the patch restricts itself to EHCI host controllers. Finally the affected systems can suspend with USB wakeup working properly. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728 Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Javier Marcet <jmarcet@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Oleksij Rempel <bug-track@fisher-privat.net> Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2Alan Stern2012-06-221-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b upstream. This patch (as1558) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. A similar patch has already been applied as commit 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during suspend on ASUS computers). The patch supersedes that one and reverts it. There are two differences: The old patch added the flag at the USB level; this patch adds it at the PCI level. The old patch applied to all chipsets with the same vendor, subsystem vendor, and product IDs; this patch makes an exception for a known-good system (based on DMI information). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUsThomas Jarosch2012-04-271-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream. Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-. These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts. Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug. Tested on the following boards: - Intel DH61CR: Affected - Intel DH67BL: Affected - Intel S1200KP server board: Affected - Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed. According to reports on the net, the Intel DH61WW board is also affected. Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation. Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Tested-by: Charlie Suffin <charlie.suffin@stratus.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PCI quirk: mmc: Always check for lower base frequency quirk for Ricoh 1180:e823Josh Boyer2011-11-111-14/+14
| | | | | | | | | | | | | | | | | | | | | | commit 3e309cdf07c930f29a4e0f233e47d399bea34c68 upstream. Commit 15bed0f2f added a quirk for the e823 Ricoh card reader to lower the base frequency. However, the quirk first checks to see if the proprietary MMC controller is disabled, and returns if so. On some devices, such as the Lenovo X220, the MMC controller is already disabled by firmware it seems, but the frequency change is still needed so sdhci-pci can talk to the cards. Since the MMC controller is disabled, the frequency fixup was never being run on these machines. This moves the e823 check above the MMC controller check so that it always gets run. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=722509 Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* mmc: Added quirks for Ricoh 1180:e823 lower base clock frequencyManoj Iyer2011-08-041-0/+23
| | | | | | | | | | | | | | | | | | | | | commit 15bed0f2fa8e1d7db201692532c210a7823d2d21 upstream. Ricoh 1180:e823 does not recognize certain types of SD/MMC cards, as reported at http://launchpad.net/bugs/773524. Lowering the SD base clock frequency from 200Mhz to 50Mhz fixes this issue. This solution was suggest by Koji Matsumuro, Ricoh Company, Ltd. This change has no negative performance effect on standard SD cards, though it's quite possible that there will be one on UHS-1 cards. Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Tested-by: Daniel Manrique <daniel.manrique@canonical.com> Cc: Koji Matsumuro <matsumur@nts.ricoh.co.jp> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* mmc: Add PCI fixup quirks for Ricoh 1180:e823 readerManoj Iyer2011-06-181-0/+2
| | | | | | Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Cc: <stable@kernel.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* PCI: Don't use dmi_name_in_vendors in quirkJean Delvare2011-05-211-2/+5
| | | | | | | | | Don't use the costly dmi_name_in_vendors() when we know the string we are looking for can only be in the DMI board name field. This is more robust and, more importantly, much faster. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Use ICH6_GPIO_EN in ich6_lpc_acpi_gpioJean Delvare2011-05-101-1/+1
| | | | | | | | We were just lucky that ICH4_GPIO_EN and ICH6_GPIO_EN happen to have the same value. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Fix typo in ich7 quirk commentJean Delvare2011-05-101-1/+1
| | | | | Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Add quirk for setting valid class for TI816X EndpointHemant Pedanekar2011-05-101-0/+10
| | | | | | | | | | | | | | | | | | TI816X (common name for DM816x/C6A816x/AM389x family) devices configured to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus code to skip allocating BARs to these devices resulting into following type of error when trying to enable them: "Device 0000:01:00.0 not available because of resource collisions" The device cannot be operated because of the above issue. This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based) 'early' fixup quirk to replace class code with PCI_CLASS_MULTIMEDIA_VIDEO as class. Signed-off-by: Hemant Pedanekar <hemantp@ti.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Fix common misspellingsLucas De Marchi2011-03-311-2/+2
| | | | | | Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
* PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICHJiri Slaby2011-03-041-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some broken BIOSes on ICH4 chipset report an ACPI region which is in conflict with legacy IDE ports when ACPI is disabled. Even though the regions overlap, IDE ports are working correctly (we cannot find out the decoding rules on chipsets). So the only problem is the reported region itself, if we don't reserve the region in the quirk everything works as expected. This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO which is 0x1000. Some regions might be (and are by a fast google query) below this border, but the only difference is that they won't be reserved anymore. They should still work though the same as before. The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl): pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f] At 0x0100 a 128 bytes long ACPI region is reported in the quirk for ICH4. ata_piix then fails to find disks because the IDE legacy ports are zeroed: ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007]) References: https://bugzilla.novell.com/show_bug.cgi?id=558740 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: add more checking to ICH region quirksJiri Slaby2011-03-041-8/+37
| | | | | | | | | | | | | | Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN and GPIO_EN bits are set to 1. Add checks for these bits into the quirks prior to the region creation. While at it, name the constants by macros. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: remove quirk for pre-production systemsBrandeburg, Jesse2011-02-161-52/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 7eb93b175d4de9438a4b0af3a94a112cb5266944 Author: Yu Zhao <yu.zhao@intel.com> Date: Fri Apr 3 15:18:11 2009 +0800 PCI: SR-IOV quirk for Intel 82576 NIC If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash BAR and program the SR-IOV BARs to use the old Flash Memory Space. Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet section 7.9.2.14.2 for details. http://download.intel.com/design/network/datashts/82576_Datasheet.pdf Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> This quirk was added before SR-IOV was in production and now all machines that originally had this issue alreayd have bios updates to correct the issue. The quirk itself is no longer needed and in fact causes bugs if run. Remove it. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Yu Zhao <yu.zhao@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
*-. Merge branches 'x86-fixes-for-linus' and 'perf-fixes-for-linus' of ↵Linus Torvalds2010-12-191-0/+23
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86-32: Make sure we can map all of lowmem if we need to x86, vt-d: Handle previous faults after enabling fault handling x86: Enable the intr-remap fault handling after local APIC setup x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic x86, xsave: Use alloc_bootmem_align() instead of alloc_bootmem() bootmem: Add alloc_bootmem_align() x86, gcc-4.6: Use gcc -m options when building vdso x86: HPET: Chose a paranoid safe value for the ETIME check x86: io_apic: Avoid unused variable warning when CONFIG_GENERIC_PENDING_IRQ=n * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: perf: Fix off by one in perf_swevent_init() perf: Fix duplicate events with multiple-pmu vs software events ftrace: Have recordmcount honor endianness in fn_ELF_R_INFO scripts/tags.sh: Add magic for trace-events tracing: Fix panic when lseek() called on "trace" opened for writing
| * | x86, vt-d: Quirk for masking vtd spec errors to platform error handling logicSuresh Siddha2010-12-131-0/+23
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On platforms with Intel 7500 chipset, there were some reports of system hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled. During kdump, there is a window where the devices might be still using old kernel's interrupt information, while the kdump kernel is coming up. This can cause vt-d faults as the interrupt configuration from the old kernel map to null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled, we still have the same issue but in this case we will see benign spurious interrupt hit the new kernel). Based on platform config settings, these platforms seem to generate NMI/SMI when a vt-d fault happens and there were reports that the resulting SMI causes the system to hang. Fix it by masking vt-d spec defined errors to platform error reporting logic. VT-d spec related errors are already handled by the VT-d OS code, so need to report the same error through other channels. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com> Cc: stable@kernel.org [v2.6.32+] Reported-by: Max Asbock <masbock@linux.vnet.ibm.com> Reported-and-tested-by: Takao Indoh <indou.takao@jp.fujitsu.com> Acked-by: Chris Wright <chrisw@sous-sol.org> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
* | PCI: Update MCP55 quirk to not affect non HyperTransport variantsNeil Horman2010-12-161-0/+3
|/ | | | | | | | | | | | | | | | | | | | | | I wrote this quirk awhile ago to properly setup MCP55 chips on hypertransport busses so that interrupts reached whatever cpu happend to boot the kdump kernel. while that works well, it was recently shown to me that a a non-hypertransport variant of the MCP55 exists, and on those system the register that this quirk manipulates causes hangs if you write to it. Since the quirk was only meant to handle errors found on MCP55 chips that have a HT interface, this patch adds a filter to make sure the chip is an HT capable before making the needed register adjustment. This lets the broken MCP55s work with kdump while not breaking the non-HT variants. Resolves https://bugzilla.kernel.org/show_bug.cgi?id=23952 Tested successfully by the reporter and myself. Cc: stable@kernel.org Reported-by: Mathieu Bérard <mathieu@mberard.eu> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* pci root complex: support for tile architectureChris Metcalf2010-11-241-0/+18
| | | | | | | | | | | | | | | | | | | This change enables PCI root complex support for TILEPro. Unlike TILE-Gx, TILEPro has no support for memory-mapped I/O, so the PCI support consists of hypervisor upcalls for PIO, DMA, etc. However, the performance is fine for the devices we have tested with so far (1Gb Ethernet, SATA, etc.). The <asm/io.h> header was tweaked to be a little bit more aggressive about disabling attempts to map/unmap IO port space. The hacky <asm/pci-bridge.h> header was rolled into the <asm/pci.h> header and the result was simplified. Both of the latter two headers were preliminary versions not meant for release before now - oh well. There is one quirk for our TILEmpower platform, which accidentally negotiates up to 5GT and needs to be kicked down to 2.5GT. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
* Merge branch 'linux-next' of ↵Linus Torvalds2010-10-281-0/+31
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (27 commits) x86: allocate space within a region top-down x86: update iomem_resource end based on CPU physical address capabilities x86/PCI: allocate space from the end of a region, not the beginning PCI: allocate bus resources from the top down resources: support allocating space within a region from the top down resources: handle overflow when aligning start of available area resources: ensure callback doesn't allocate outside available space resources: factor out resource_clip() to simplify find_resource() resources: add a default alignf to simplify find_resource() x86/PCI: MMCONFIG: fix region end calculation PCI: Add support for polling PME state on suspended legacy PCI devices PCI: Export some PCI PM functionality PCI: fix message typo PCI: log vendor/device ID always PCI: update Intel chipset names and defines PCI: use new ccflags variable in Makefile PCI: add PCI_MSIX_TABLE/PBA defines PCI: add PCI vendor id for STmicroelectronics x86/PCI: irq and pci_ids patch for Intel Patsburg DeviceIDs PCI: OLPC: Only enable PCI configuration type override on XO-1 ...
| * PCI: add quirk for non-symmetric-mode irq routing to versions 0 and 4 of the ↵Neil Horman2010-10-151-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MCP55 northbridge A long time ago I worked on a RHEL5 bug in which kdump hung during boot on a set of systems. The systems hung because they never received timer interrupts during calibrate_delay. These systems also all had Opteron processors on a hypertransport bus, bridged to a pci bus via an Nvidia MCP55 northbridge chip. After much wrangling I managed to learn from Nvidia that they have an undocumented register in some versions of that chip which control how legacy interrupts are send to the cpu complex when the ioapic isn't active. Nvidia defaults this register to only send legacy interrupts to the BSP, so if kdump happens to boot on an AP, we never get timer interrupts and boom. I had initially used this quirk as a workaround, with my intent being to move apic initalization to an earlier point in the boot process, so the setting of the register would be irrelevant. Given the work involved in doing that however, the fragile nature of the apic initalization code, and the fact that, over the 2 years since we found this bug, the MCP55 is the only chip which seems to have this issue, I've figure at this point its likely safer to just carry the quirk around. By setting the referenced bits in this hidden register, interrupts will be broadcast to all cpus when the ioapic isn't active on the above described systems. Acked-by: Simon Horman <horms@verge.net.au> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | Merge branch 'for-next' of ↵Linus Torvalds2010-10-241-1/+2
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Update broken web addresses in the kernel.Justin P. Mattock2010-10-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch below updates broken web addresses in the kernel Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Matt Turner <mattst88@gmail.com> Cc: Dimitry Torokhov <dmitry.torokhov@gmail.com> Cc: Mike Frysinger <vapier.adi@gmail.com> Acked-by: Ben Pfaff <blp@cs.stanford.edu> Acked-by: Hans J. Koch <hjk@linutronix.de> Reviewed-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hangLen Brown2010-09-241-0/+20
|/ | | | | | | | | | | | | | | | | When the Lenovo Ideapad S10-3 is booted with HT enabled, it hits a boot hang in the intel_idle driver. This occurs when entering ATM-C4 for the first time, unless BM_STS is first cleared. acpi_idle doesn't see this because it first checks and clears BM_STS, but it would hit the same hang if that check were disabled. http://bugs.meego.com/show_bug.cgi?id=7093 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/634702 Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'linux-next' of ↵Linus Torvalds2010-08-061-4/+38
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (30 commits) PCI: update for owner removal from struct device_attribute PCI: Fix warnings when CONFIG_DMI unset PCI: Do not run NVidia quirks related to MSI with MSI disabled x86/PCI: use for_each_pci_dev() PCI: use for_each_pci_dev() PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc() PCI: export SMBIOS provided firmware instance and label to sysfs PCI: Allow read/write access to sysfs I/O port resources x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLAN PCI: remove unused HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_{SIZE|BOUNDARY} PCI: disable mmio during bar sizing PCI: MSI: Remove unsafe and unnecessary hardware access PCI: Default PCIe ASPM control to on and require !EMBEDDED to disable PCI: kernel oops on access to pci proc file while hot-removal PCI: pci-sysfs: remove casts from void* ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe PCI hotplug: make sure child bridges are enabled at hotplug time PCI hotplug: shpchp: Removed check for hotplug of display devices PCI hotplug: pciehp: Fixed return value sign for pciehp_unconfigure_device PCI: Don't enable aspm before drivers have had a chance to veto it ...
| * PCI: Do not run NVidia quirks related to MSI with MSI disabledRafael J. Wysocki2010-07-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no reason to run NVidia-specific quirks related to HT MSI mappings with MSI disabled via pci=nomsi, so make __nv_msi_ht_cap_quirk() return immediately in that case. This allows at least one machine to boot 100% of the time with pci=nomsi (it still doesn't boot reliably without that). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16443 . Cc: stable@kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: use for_each_pci_dev()Kulikov Vasiliy2010-07-301-1/+1
| | | | | | | | | | | | | | Use for_each_pci_dev() to simplify the code. Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: disable mmio during bar sizingJacob Pan2010-07-301-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is a known issue that mmio decoding shall be disabled while doing PCI bar sizing. Host bridge and other devices (PCI PIC) shall be excluded for certain platforms. This patch mainly comes from Mathew Willcox's patch in http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/258969. A new flag bit "mmio_alway_on" is added to pci_dev with the intention that devices with their mmio decoding cannot be disabled during BAR sizing shall have this bit set, preferrablly in their quirks. Without this patch, Intel Moorestown platform graphics unit will be corrupted during bar sizing activities. Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: disable MSI on VIA K8M800Tejun Heo2010-07-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | MSI delivery from on-board ahci controller doesn't work on K8M800. At this point, it's unclear whether the culprit is with the ahci controller or the host bridge. Given the track record and considering the rather minimal impact of MSI, disabling it seems reasonable. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI quirk: AMD 780: work around wrong vendor ID on APC bridgeClemens Ladisch2010-07-301-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In all AMD 780 family northbridges, the vendor ID of the internal graphics PCI/PCI bridge reads not as AMD but as that of the mainboard vendor, because the hardware actually returns the value of the subsystem vendor ID (erratum 18). We currently have additional quirk entries for Asus and Acer, but it is likely that we will encounter more systems with other vendor IDs. Since we do not know in advance all possible vendor IDs, a better way to find the device is to declare the quirk on the host bridge, whose ID is always correct, and use that device as a stepping stone to find the PCI/ PCI bridge, if present. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | libata: more PCI IDs for jmicron controllersTejun Heo2010-08-011-0/+6
|/ | | | | | | | Add support for JMB364 and 369. Patch-originally-from: Aries Lee <arieslee@jmicron.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* ahci: add pci quirk for JMB362Tejun Heo2010-06-071-1/+4
| | | | | | | | | | | | JMB362 is a new variant of jmicron controller which is similar to JMB360 but has two SATA ports instead of one. As there is no PATA port, single function AHCI mode can be used as in JMB360. Add pci quirk for JMB362. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Aries Lee <arieslee@jmicron.com> Cc: stable@kernel.org Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* PCI: Allow manual resource allocation for PCI hotplug bridgesFelix Radensky2010-05-211-0/+13
| | | | | | | | | | | | | | | | At the moment only PCI-E briges can be flagged as hotplug, thus allowing manual resource preallocation via pci=hpmemsize=nnM and pci=hpiosize=nnM kernel parameters. Some PCI hotplug bridges, e.g. PLX 6254 can also benefit from this functionalily, as kernel fails to properly allocate their resources when hotplug device is added and PCI bus is rescanned. This patch adds header quirk for PLX 6254 that marks this bridge as hotplug. Other PCI bridges with similar problems can use it as well. Signed-off-by: Felix Radensky <felix@embedded-sol.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI quirks: disable msi on AMD rs4xx internal gfx bridgesAlex Deucher2010-05-181-0/+1
| | | | | | | | | Doesn't work reliably for internal gfx. Fixes kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=15626. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: Stable <stable@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Disable MSI for MCP55 on P5N32-E SLIBen Hutchings2010-05-181-3/+4
| | | | | | | | | | | As reported in <http://bugs.debian.org/552299>, MSI appears to be broken for this on-board device. We already have a quirk for the P5N32-SLI Premium; extend it to cover both variants of the board. Reported-by: Romain DEGEZ <romain.degez@smartjog.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI quirk: RS780/RS880: disable MSI behind the PCI bridgeClemens Ladisch2010-04-021-33/+3
| | | | | | | | | | | | | | The missing initialization of the nb_cntl.strap_msi_enable does not seem to be the only problem that prevents MSI, so that quirk is not sufficient to enable MSI on all machines. To be safe, disable MSI unconditionally for the internal graphics and HDMI audio on these chipsets. [rjw: Added the PCI_VENDOR_ID_AI quirk.] Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: don't say we claimed a resource if we failedBjorn Helgaas2010-03-251-2/+3
| | | | | | | | | pci_claim_resource() can fail, so pay attention and only claim success when it actually succeeded. If pci_claim_resource() fails, it prints a useful diagnostic. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI quirk: Disable MSI on VIA K8T890 systemsMatthew Wilcox2010-03-251-0/+1
| | | | | | | | | | | Bugzilla 15287 indicates that there's a problem with Message Signalled Interrupts on VIA K8T890 systems. Add a quirk to disable MSI on these systems. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Tested-by: Jan Kreuzer <kontrollator@gmx.de> Tested-by: lh <jarryson@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI quirk: RS780/RS880: work around missing MSI initializationClemens Ladisch2010-03-241-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | AMD says in section 2.5.4 (GFX MSI Enable) of #43291 (AMD 780G Family Register Programming Requirements): The SBIOS must enable internal graphics MSI capability in GCCFG by setting the following: NBCFG.NB_CNTL.STRAP_MSI_ENABLE='1' Quite a few BIOS writers misinterpret this sentence and think that enabling MSI is an optional feature. However, clearing that bit just prevents delivery of MSI messages but does not remove the MSI PCI capabilities registers, and so leaves these devices unusable for any driver that attempts to use MSI. Setting that bit is not possible after the BIOS has locked down the configuration registers, so we have to manually disable MSI for the affected devices. This fixes the codec communication errors in the HDA driver when accessing the HDMI audio device, and allows us to get rid of the overcautious quirk in radeon_irq_kms.c. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Tested-by: Alex Deucher <alexdeucher@gamil.com> Cc: <stable@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI quirk: only apply CX700 PCI bus parking quirk if external VT6212L is presentTim Yamin2010-03-241-3/+17
| | | | | | | | | | | | | | | | Apply the CX700 quirk only when an external VT6212L is present (which is the case for the errant hardware the quirk was written for), don't touch the settings otherwise -- Hauppage PVR-500 tuners need PCI Bus Parking in order to work and when that's turned on everything seems to behave fine. I guess the underlying problem is a combination of an external VT6212L and the CX700 rather than the CX700's PCI being broken completely for all cases... Reported-by: Jeroen Roos <jeroen@roosnl.com> Signed-off-by: Tim Yamin <plasm@roo.me.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ricoh_mmc: port from driver to pci quirkMaxim Levitsky2010-03-061-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch solves nasty problem original driver has. Original goal of the ricoh_mmc was to disable this device because then, mmc cards can be read using standard SDHCI controller, thus avoiding writing of yet another driver. However, the act of disablement, makes other pci functions that belong to this controller (xD and memstick) shift up one level, thus pci core has now wrong idea about these devices. To fix this issue, this patch moves the driver into the pci quirk section, thus it is executes before the pci is enumerated, and therefore solving that issue, also same sequence of commands is performed on resume for same reasons. Also regardless of the above, this way is cleaner. You still need to set CONFIG_MMC_RICOH_MMC to enable this quirk Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> Acked-by: Philip Langdale <philipl@overt.org> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller2010-02-281-12/+2
|\ | | | | | | | | Conflicts: drivers/firmware/iscsi_ibft.c
| * PCI: Clean up build for CONFIG_PCI_QUIRKS unsetRafael J. Wysocki2010-02-221-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, drivers/pci/quirks.c is built unconditionally, but if CONFIG_PCI_QUIRKS is unset, the only things actually built in this file are definitions of global variables and empty functions (due to the #ifdef CONFIG_PCI_QUIRKS embracing all of the code inside the file). This is not particularly nice and if someone overlooks the #ifdef CONFIG_PCI_QUIRKS, build errors are introduced. To clean that up, move the definitions of the global variables in quirks.c that are always built to pci.c, move the definitions of the empty functions (compiled when CONFIG_PCI_QUIRKS is unset) to headers (additionally make these functions static inline) and modify drivers/pci/Makefile so that quirks.c is only built if CONFIG_PCI_QUIRKS is set. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | pci: add support for 82576NS serdes to existing SR-IOV quirkAlexander Duyck2010-02-221-0/+1
|/ | | | | | | | | This patch adds support for the 82576NS Serdes adapter to the existing pci quirk for 82576 parts. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* CS5536: apply pci quirk for BIOS SMBUS bugAndres Salomon2010-02-051-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | The new cs5535-* drivers use PCI header config info rather than MSRs to determine the memory region to use for things like GPIOs and MFGPTs. As anticipated, we've run into a buggy BIOS: [ 0.081818] pci 0000:00:14.0: reg 10: [io 0x6000-0x7fff] [ 0.081906] pci 0000:00:14.0: reg 14: [io 0x6100-0x61ff] [ 0.082015] pci 0000:00:14.0: reg 18: [io 0x6200-0x63ff] [ 0.082917] pci 0000:00:14.2: reg 20: [io 0xe000-0xe00f] [ 0.083551] pci 0000:00:15.0: reg 10: [mem 0xa0010000-0xa0010fff] [ 0.084436] pci 0000:00:15.1: reg 10: [mem 0xa0011000-0xa0011fff] [ 0.088816] PCI: pci_cache_line_size set to 32 bytes [ 0.088938] pci 0000:00:14.0: address space collision: [io 0x6100-0x61ff] already in use [ 0.089052] pci 0000:00:14.0: can't reserve [io 0x6100-0x61ff] This is a Soekris board, and its BIOS sets the size of the PCI ISA bridge device's BAR0 to 8k. In reality, it should be 8 bytes (BAR0 is used for SMBus stuff). This quirk checks for an incorrect size, and resets it accordingly. Signed-off-by: Andres Salomon <dilinger@collabora.co.uk> Tested-by: Leigh Porter <leigh@leighporter.org> Tested-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pci: avoid compiler warning in quirks.cLinus Torvalds2009-12-311-1/+1
| | | | | | | | | | | | | | Introduced by commit 5b889bf23 ("PCI: Fix build if quirks are not enabled"), which made the pci_dev_reset_methods[] array static and 'const', but didn't then change the code to match, and use a const pointer when moving it to quirks.c. Trivially fixed by just adding the required 'const' to the iterator variable. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: Fix build if quirks are not enabledRafael J. Wysocki2009-12-311-1/+18
| | | | | | | | | | | | | After commit b9c3b266411d27f1a6466c19d146d08db576bfea ("PCI: support device-specific reset methods") the kernel build is broken if CONFIG_PCI_QUIRKS is unset. Fix this by moving pci_dev_specific_reset() to drivers/pci/quirks.c and providing an empty replacement for !CONFIG_PCI_QUIRKS builds. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: add Intel 82599 Virtual Function specific reset methodDexuan Cui2009-12-161-0/+22
| | | | | | | | Handle device specific timeout and use FLR. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: add Intel USB specific reset methodDexuan Cui2009-12-161-0/+24
| | | | | | | | | Handle device specific reset requirements (i.e. vendor reg for reset along with appropriate timeout). Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>