With increasing number of PCI function ids, add the PCI function id
in the define name instead of its symbolic name in the BKDG for more
clarity.
Acked-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Signed-off-by: NAries Lee <arieslee@jmicron.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: Alex Dubov <oakad@yahoo.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

JMicron 388 SD/MMC combo controller supports the 1.8V low-voltage for
SD, but MMC doesn't work with the low-voltage, resulting in an error
at probing.

This patch adds the support for multiple voltage mask per device type,
so that SD works with 1.8V while MMC forces 3.3V.  Here new ocr_avail_*
fields for each device are introduced, so that the actual OCR mask is
switched dynamically.

Also, the restriction of low-voltage in core/sd.c is removed when the
bit is allowed explicitly via ocr_avail_sd mask.

This patch was rewritten from scratch based on Aries' original code.
Signed-off-by: NAries Lee <arieslee@jmicron.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NChris Ball <cjb@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch disables the broken ADMA on selected O2Micro devices.
Signed-off-by: NJennifer Li <Jennifer.li@o2micro.com>
Reviewed-by: NChris Ball <cjb@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch adds the PCI northbridge device id for AMD CPU
families 12h and 14h. Both families have implemented the same
PCI northbridge device.

There are some future use cases that use this PCI device and
we would like to clarify its naming.
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Cc: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <JBeulich@novell.com>
LKML-Reference: <20110106165107.GL4739@erda.amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This patch adds an additional LPC Controller DeviceID for the Intel
Patsburg PCH.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Add new vendor for Broadcom 4318.
Signed-off-by: NDaniel Klaffenbach <danielklaffenbach@gmail.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

SDHC2 is newly added in C0 stepping of Langwell. Without the Moorestown
specific quirk, the default pci_probe will be called and crash the kernel.

This patch unblocks the crash problem on C0 by using the same probing
function as HC1, which limits the number of slots to one.
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add support for the Intel Patsburg PCH SMBus Controller.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Basic support for the Intel Medfield devices

Give them their own quirks as we will need to update this later.
Signed-off-by: NXiaochen Shen <xiaochen.shen@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

cciss: fix PCI IDs for new controllers

This patch fixes the botched up PCI IDs of new controllers. Please consider
this patch for inclusion.
Signed-off-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>

This patch updates the defines for Intel devices in
include/linux/pci_ids.h, referenced in arch/x86/pci/irq.c and
drivers/i2c/busses/i2c-i801.c, reflecting approved legal branding, and
using fuller code-names for products under development.
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NAnders Wallin <anders.wallin@windriver.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch adds the LPC Controller DeviceIDs for the Intel Patsburg PCH.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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: NSimon Horman <horms@verge.net.au>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

AMD CPU family 0x15 still supports GART for compatibility reasons.
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
LKML-Reference: <20100930124316.GG20545@loge.amd.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

This patch adds a workaround for an IOMMU BIOS problem to
the AMD IOMMU driver. The result of the bug is that the
IOMMU does not execute commands anymore when the system
comes out of the S3 state resulting in system failure. The
bug in the BIOS is that is does not restore certain hardware
specific registers correctly. This workaround reads out the
contents of these registers at boot time and restores them
on resume from S3. The workaround is limited to the specific
IOMMU chipset where this problem occurs.

Cc: stable@kernel.org
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Previously these IDs were only used by one driver, so there was not much
need for having them generically defined. Now that this will no longer
hold true, move them over.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This is needed for proper PCI-E support on P1021 SoCs.
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is patch 1/6 which contains linux driver source for
Brocade's BR1010/BR1020 10Gb CEE capable ethernet adapter.
Signed-off-by: NDebashis Dutt <ddutt@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move the VENDOR/DEVICE ids to pci_ids.h.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

This patch adds the quirk for PCIE controller found on Freescale MPC8308.
The quirk is the same as for other MPC83xx processors.
Signed-off-by: NIlya Yanok <yanok@emcraft.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

SBE 2T3E3 cards use DECchips 21143 but they need a different driver.
Don't even try to use a normal tulip driver with them.
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These devices were never released to the public.
Reviewed-by: NBenjamin Li <benli@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for JMB364 and 369.

Patch-originally-from: Aries Lee <arieslee@jmicron.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Add the xen pci platform device driver that is responsible
for initializing the grant table and xenbus in PV on HVM mode.
Few changes to xenbus and grant table are necessary to allow the delayed
initialization in HVM mode.
Grant table needs few additional modifications to work in HVM mode.

The Xen PCI platform device raises an irq every time an event has been
delivered to us. However these interrupts are only delivered to vcpu 0.
The Xen PCI platform interrupt handler calls xen_hvm_evtchn_do_upcall
that is a little wrapper around __xen_evtchn_do_upcall, the traditional
Xen upcall handler, the very same used with traditional PV guests.

When running on HVM the event channel upcall is never called while in
progress because it is a normal Linux irq handler (and we cannot switch
the irq chip wholesale to the Xen PV ones as we are running QEMU and
might have passed in PCI devices), therefore we cannot be sure that
evtchn_upcall_pending is 0 when returning.
For this reason if evtchn_upcall_pending is set by Xen we need to loop
again on the event channels set pending otherwise we might loose some
event channel deliveries.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NSheng Yang <sheng@linux.intel.com>
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

For yet unknown reason, MCP89 on MBP 7,1 doesn't work w/ ahci under
linux but the controller doesn't require explicit mode setting and
works fine with ata_generic.  Make ahci ignore the controller on MBP
7,1 and let ata_generic take it for now.

Reported in bko#15923.

  https://bugzilla.kernel.org/show_bug.cgi?id=15923

NVIDIA is investigating why ahci mode doesn't work.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Peer Chen <pchen@nvidia.com>
Cc: stable@kernel.org
Reported-by: NAnders Østhus <grapz666@gmail.com>
Reported-by: NAndreas Graf <andreas_graf@csgraf.de>
Reported-by: NBenoit Gschwind <gschwind@gnu-log.net>
Reported-by: NDamien Cassou <damien.cassou@gmail.com>
Reported-by: tixetsal@juno.com
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

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: NTejun Heo <tj@kernel.org>
Reported-by: NAries Lee <arieslee@jmicron.com>
Cc: stable@kernel.org
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This adds new PCI IDs for the Westmere's memory controller
devices and modifies the i7core_edac driver to be able to
probe both Nehalem and Westmere processors.
Signed-off-by: NVernon Mauery <vernux@us.ibm.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As reported by Vernon Mauery <vernux@us.ibm.com>, X5670 (Westmere-EP) uses a
different register for one of the uncore PCI devices. Add support for
it.

Those are the PCI ID's on this new chipset:

fe:00.0 0600: 8086:2c70 (rev 02)
fe:00.1 0600: 8086:2d81 (rev 02)
fe:02.0 0600: 8086:2d90 (rev 02)
fe:02.1 0600: 8086:2d91 (rev 02)
fe:02.2 0600: 8086:2d92 (rev 02)
fe:02.3 0600: 8086:2d93 (rev 02)
fe:02.4 0600: 8086:2d94 (rev 02)
fe:02.5 0600: 8086:2d95 (rev 02)
fe:03.0 0600: 8086:2d98 (rev 02)
fe:03.1 0600: 8086:2d99 (rev 02)
fe:03.2 0600: 8086:2d9a (rev 02)
fe:03.4 0600: 8086:2d9c (rev 02)
fe:04.0 0600: 8086:2da0 (rev 02)
fe:04.1 0600: 8086:2da1 (rev 02)
fe:04.2 0600: 8086:2da2 (rev 02)
fe:04.3 0600: 8086:2da3 (rev 02)
fe:05.0 0600: 8086:2da8 (rev 02)
fe:05.1 0600: 8086:2da9 (rev 02)
fe:05.2 0600: 8086:2daa (rev 02)
fe:05.3 0600: 8086:2dab (rev 02)
fe:06.0 0600: 8086:2db0 (rev 02)
fe:06.1 0600: 8086:2db1 (rev 02)
fe:06.2 0600: 8086:2db2 (rev 02)
fe:06.3 0600: 8086:2db3 (rev 02)
(as usual, the same PCI devices repeat at ff: bus)

The PCI device 8086:2c70 is shown as:

fe:00.0 Host bridge: Intel Corporation QuickPath Architecture Generic
Non-core Registers (rev 02)

So, for this device to be recognized, it is only a matter of adding this
new PCI ID to the driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch adds additional LPC Controller DeviceIDs for the Intel Cougar
Point PCH.

The DeviceIDs are defined and referenced as a range of values, the same
way Ibex Peak was implemented.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Xeon55xx fails to probe with this error message:

EDAC DEBUG: in drivers/edac/i7core_edac.c, line at 1660: MC: drivers/edac/i7core_edac.c: i7core_init()
EDAC i7core: Device not found: dev 00:00.0 PCI ID 8086:2c41
i7core_edac: probe of 0000:00:14.0 failed with error -22

This is due to the fact that, on Xeon35xx (and i7core), device 00.0 has
PCI ID 8086:2c40.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This code changes the detection procedure of i7core_edac. Instead of
directly probing for MC registers, it probes for another register found
on Nehalem. If found, it tries to pick the first MC PCI BUS. This should
work fine with Xeon 35xx, but, on Xeon 55xx, this is at bus 254 and 255
that are not properly detected by the non-legacy PCI methods.

The new detection code scans specifically at buses 254 and 255 for the
Xeon 55xx devices.

This code has not tested yet. After working, a change at the code will
be needed, since the i7core is not yet ready for working with 2 sets of
MC.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The public Intel Xeon 5500 volume 2 datasheet describes, on page 53,
session 2.6.7 a register that can lock/unlock Memory Controller the
configuration register, called MC_CFG_CONTROL.

Adds support for it in the hope that software error injection would
work. With my tests with Xeon 35xx, there's still something missing.
With a program that does sequencial bit writes at dev 0.0, sometimes, it
produces error injection, after unblocking the MC_CFG_CONTROL (and,
sometimes, it just locks my testing machine).

I'll try later to discover by trial and error what's the register that
solves this issue on Xeon 35xx.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This driver is meant to support i7 core/i7core extreme desktop
processors and Xeon 35xx/55xx series with integrated memory controller.
It is likely that it can be expanded in the future to work with other
processor series based at the same Memory Controller design.

For now, it has just a few MCH status reads.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>