Previously we had to have CONFIG_PCI_DEBUG=y or CONFIG_DYNAMIC_DEBUG=y
to turn on this printk, but I think the IDs are valuable enough that it's
worth putting them in the log always.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Replace EXTRA_CFLAGS with ccflags-y.
Signed-off-by: Nmatt mooney <mfm@muteddisk.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

These are already defined in pcilib's pci/header.h but not in kernel's
linux/pci_regs.h.  Copy them to avoid using magic numbers.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.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>

There is a design issue related to PCIe AER and _OSC that the BIOS
may be asked to grant control of the AER service even if some
Hardware Error Source Table (HEST) entries contain information
meaning that the BIOS really should control it.  Namely,
pcie_port_acpi_setup() calls pcie_aer_get_firmware_first() that
determines whether or not the AER service should be controlled by
the BIOS on the basis of the HEST information for the given PCIe
port.  The BIOS is asked to grant control of the AER service for
a PCIe Root Complex if pcie_aer_get_firmware_first() returns 'false'
for at least one root port in that complex, even if all of the other
root ports' HEST entries have the FIRMWARE_FIRST flag set (and none
of them has the GLOBAL flag set).  However, if the AER service is
controlled by the kernel, that may interfere with the BIOS' handling
of the error sources having the FIRMWARE_FIRST flag.  Moreover,
there may be PCIe endpoints that have the FIRMWARE_FIRST flag set in
HEST and are attached to the root ports in question, in which case it
also may be unsafe to ask the BIOS for control of the AER service.

For this reason, introduce a function checking if there's at least
one PCIe-related HEST entry with the FIRMWARE_FIRST flag set and
disable the native AER service altogether if this function returns
'true'.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Get rid of init_MUTEX[_LOCKED]() and use sema_init() instead.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

quiet the warning about use of uninitialized e_src in
aer_isr()  e_src is initialized by get_e_source()
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

All operations in the pci procfs ioctl functions are
atomic, so no lock is needed here.

Also add a compat_ioctl method, since all the commands
are compatible in 32 bit mode.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-pci@vger.kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Indent the branch of an if.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable braces4@
position p1,p2;
statement S1,S2;
@@

(
if (...) { ... }
|
if (...) S1@p1 S2@p2
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

if (p1[0].column == p2[0].column):
  cocci.print_main("branch",p1)
  cocci.print_secs("after",p2)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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/634702Signed-off-by: NLen Brown <len.brown@intel.com>

drivers/pci/intel-iommu.c: In function `__iommu_calculate_agaw':
drivers/pci/intel-iommu.c:437: sorry, unimplemented: inlining failed in call to 'width_to_agaw': function body not available
drivers/pci/intel-iommu.c:445: sorry, unimplemented: called from here

Move the offending function (and its siblings) to top-of-file, remove the
forward declaration.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=17441Reported-by: NMartin Mokrejs <mmokrejs@ribosome.natur.cuni.cz>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 9eecabcb ("intel-iommu: Abort 
IOMMU setup for igfx if BIOS gave no shadow GTT space") uses a bunch of 
magic numbers. Provide #defines for those to make it look slightly saner.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Yet another BIOS bug; Lenovo this time (X201). Red Hat bug #593516.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This fixes the prototype for both pci_resource_alignment() and
pci_sriov_resource_alignment().

Patch started as debugging effort from Cam Macdonell.

Cc: Cam Macdonell <cam@cs.ualberta.ca>
Cc: Avi Kivity <avi@redhat.com>
[chrisw: add iov bits]
Signed-off-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

One of the recent changes caused complilation of
drivers/pci/hotplug/pciehp_core.c to fail.  Fix this issue.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The PCIe port driver's module exit routine is never used, so drop it.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The PCIe PME code only consists of one file, so it doesn't need to
occupy its own directory.  Move it to drivers/pci/pcie/pme.c and
remove the contents of drivers/pci/pcie/pme .
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

In principle PCIe port services may be enabled by the BIOS, so it's
better to disable them during port initialization to avoid spurious
events from being generated.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

After commit 852972ac (ACPI: Disable
ASPM if the platform won't provide _OSC control for PCIe) control of
the PCIe Capability Structure is unconditionally requested by
acpi_pci_root_add(), which in principle may cause problems to
happen in two ways.  First, the BIOS may refuse to give control of
the PCIe Capability Structure if it is not asked for any of the
_OSC features depending on it at the same time.  Second, the BIOS may
assume that control of the _OSC features depending on the PCIe
Capability Structure will be requested in the future and may behave
incorrectly if that doesn't happen.  For this reason, control of
the PCIe Capability Structure should always be requested along with
control of any other _OSC features that may depend on it (ie. PCIe
native PME, PCIe native hot-plug, PCIe AER).

Rework the PCIe port driver so that (1) it checks which native PCIe
port services can be enabled, according to the BIOS, and (2) it
requests control of all these services simultaneously.  In
particular, this causes pcie_portdrv_probe() to fail if the BIOS
refuses to grant control of the PCIe Capability Structure, which
means that no native PCIe port services can be enabled for the PCIe
Root Complex the given port belongs to.  If that happens, ASPM is
disabled to avoid problems with mishandling it by the part of the
PCIe hierarchy for which control of the PCIe Capability Structure
has not been received.

Make it possible to override this behavior using 'pcie_ports=native'
(use the PCIe native services regardless of the BIOS response to the
control request), or 'pcie_ports=compat' (do not use the PCIe native
services at all).

Accordingly, rework the existing PCIe port service drivers so that
they don't request control of the services directly.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

It is possible that the BIOS will not grant control of all _OSC
features requested via acpi_pci_osc_control_set(), so it is
recommended to negotiate the final set of _OSC features with the
query flag set before calling _OSC to request control of these
features.

To implement it, rework acpi_pci_osc_control_set() so that the caller
can specify the mask of _OSC control bits to negotiate and the mask
of _OSC control bits that are absolutely necessary to it.  Then,
acpi_pci_osc_control_set() will run _OSC queries in a loop until
the mask of _OSC control bits returned by the BIOS is equal to the
mask passed to it.  Also, before running the _OSC request
acpi_pci_osc_control_set() will check if the caller's required
control bits are present in the final mask.

Using this mechanism we will be able to avoid situations in which the
BIOS doesn't grant control of certain _OSC features, because they
depend on some other _OSC features that have not been requested.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Introduce kernel command line switch pcie_ports= allowing one to
disable all of the native PCIe port services, so that PCIe ports
are treated like PCI-to-PCI bridges.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Introduce a function allowing the caller to check whether to try to
enable PCIe AER.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

drivers/pci/intel-iommu.c: In function 'dma_pte_addr':
drivers/pci/intel-iommu.c:239: warning: passing argument 1 of '__cmpxchg64' from incompatible pointer type

It seems that __cmpxchg64() now cares about the type of its pointer argument,
so give it a (uint64_t *) instead of a pointer to a structure which contains
only that.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Allow disabling the source id checking while programming the interrupt
remap table entry. Useful for debugging or working around the broken
source id checks on some platforms.
Signed-off-by: NChris Wright <chrisw@redhat.com>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: NWeidong Han <weidong.han@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Commit 69309a05 ("x86, asm: Clean up and simplify set_64bit()")
sanitized the x86-64 types to set_64bit(), and incidentally resulted in
warnings like

 drivers/pci/intr_remapping.c: In function 'modify_irte':
 drivers/pci/intr_remapping.c:314: warning: passing argument 1 of 'set_64bit' from incompatible pointer type
 arch/x86/include/asm/cmpxchg_64.h:6: note:expected 'volatile u64 *' but argument is of type 'long unsigned int *'

It turns out that the change to set_64bit() really does clean up things,
and the PCI intr_remapping.c file did a rather ugly cast in order to
avoid warnings with the previous set_64bit() type model.

Removing the ugly cast fixes the warning, and makes everybody happy and
expects a set_64bit() to take the logical "u64 *" argument.
Pointed-out-by: NPeter Anvin <hpa@zytor.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes the build.
Acked-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

On some platforms (MacPro3,1) the BIOS assigns the ioatdma device to the
incorrect iommu causing faults when the driver initializes.  Add a quirk
to catch this misconfiguration and try falling back to untranslated
operation (which works in the MacPro3,1 case).

Assuming there are other platforms with misconfigured iommus teach the
ioatdma driver to treat initialization failures as non-fatal (just fail
the driver load and emit a warning instead of triggering a BUG_ON).

This can be classified as a boot regression since 2.6.32 on affected
platforms since the ioatdma module did not autoload prior to that
kernel.

Cc: <stable@kernel.org>
Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Reported-by: NChris Li <lkml@chrisli.org>
Tested-by: NChris Li <lkml@chrisli.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

This patch fixes the below warnings introduced by the commit
911e1c9b ("PCI:
export SMBIOS provided firmware instance and label to sysfs").

drivers/pci/pci.h: In function ‘pci_create_firmware_label_files’:
drivers/pci/pci.h:16: warning: ‘return’ with a value, in function returning void
drivers/pci/pci.h: In function ‘pci_remove_firmware_label_files’:
drivers/pci/pci.h:18: warning: ‘return’ with a value, in function returning void

The warnings are seen because of the below code, doing a retun 0
from the functions 'pci_create_firmware_label_files' and
'pci_remove_firmware_label_files' defined as void.

+#ifndef CONFIG_DMI
+static inline void pci_create_firmware_label_files(struct pci_dev *pdev)
+{ return 0; }
+static inline void pci_remove_firmware_label_files(struct pci_dev *pdev)
+{ return 0; }
Signed-off-by: NNarendra K <narendra_k@dell.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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>

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: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Use for_each_pci_dev() to simplify the code.
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove
unsafe and unnecessary hardware access" changed read_msi_msg_desc() to
return the last MSI message written instead of reading it from the
device, since it may be called while the device is in a reduced
power state.

However, the pSeries platform code really does need to read messages
from the device, since they are initially written by firmware.
Therefore:
- Restore the previous behaviour of read_msi_msg_desc()
- Add new functions get_cached_msi_msg{,_desc}() which return the
  last MSI message written
- Use the new functions where appropriate
Acked-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch exports SMBIOS provided firmware instance and label of
onboard PCI devices to sysfs.  New files are:
  /sys/bus/pci/devices/.../label which contains the firmware name for
the device in question, and
  /sys/bus/pci/devices/.../index which contains the firmware device type
instance for the given device.
Signed-off-by: NJordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: NNarendra K <narendra_k@dell.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

PCI sysfs resource files currently only allow mmap'ing.  On x86 this
works fine for memory backed BARs, but doesn't work at all for I/O
port backed BARs.  Add read/write to I/O port PCI sysfs resource
files to allow userspace access to these device regions.
Acked-by: NChris Wright <chrisw@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

In 2.6.34, we transformed the PCI DMA API into the generic device
mode. The PCI DMA API is just the wrapper of the DMA API.

So we don't need HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE or
HAVE_ARCH_PCI_SET_DMA_SEGMENT_BOUNDARY (which enable architectures to
have the own implementations). Both haven't been used anyway.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

During suspend on an SMP system, {read,write}_msi_msg_desc() may be
called to mask and unmask interrupts on a device that is already in a
reduced power state.  At this point memory-mapped registers including
MSI-X tables are not accessible, and config space may not be fully
functional either.

While a device is in a reduced power state its interrupts are
effectively masked and its MSI(-X) state will be restored when it is
brought back to D0.  Therefore these functions can simply read and
write msi_desc::msg for devices not in D0.

Further, read_msi_msg_desc() should only ever be used to update a
previously written message, so it can always read msi_desc::msg
and never needs to touch the hardware.
Tested-by: N"Michael Chan" <mchan@broadcom.com>
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The CONFIG_PCIEASPM option is confusing and potentially dangerous. ASPM is
a hardware mediated feature rather than one under direct OS control, and
even if the config option is disabled the system firmware may have turned
on ASPM on various bits of hardware. This can cause problems later -
various hardware that claims to support ASPM does a poor job of it and may
hang or cause other difficulties. The kernel is able to recognise this in
many cases and disable the ASPM functionality, but only if CONFIG_PCIEASPM
is enabled.

Given that in its default configuration this option will either leave the
hardware as it was originally or disable hardware functionality that may
cause problems, it should by default y. The only reason to disable it
ought to be to reduce code size, so make it dependent on CONFIG_EMBEDDED.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: lrodriguez@atheros.com
Cc: maximlevitsky@gmail.com
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

I encountered the problem that /proc/bus/pci/XX/YY is not removed even
after the corresponding device is hot-removed, if the file is still
being opened. In addtion, accessing this file in this situation causes
kernel panic (see below).

Becasue the pci_proc_detach_device() doesn't call remove_proc_entry()
if struct proc_dir_entry->count > 1, access to /proc/bus/pci/XX/YY
would refer to struct pci_dev that was already freed.

Though I don't know why the check for proc_dir_entry->count was added,
I don't think it is needed. Removing this check fixes the problem.

Steps to reproduce
------------------
# cd /sys/bus/pci/slots/2/
# PROC_BUS_PCI_FILE=/proc/bus/pci/`awk -F: '{print $2"/"$3}' < address`.0
# sleep 10000 < $PROC_BUS_PCI_FILE &
# echo 0 > power
# while true; do cat $PROC_BUS_PCI_FILE > /dev/null; done

Oops Messages
-------------
BUG: unable to handle kernel NULL pointer dereference at 00000042
IP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0
*pdpt = 000000002185e001 *pde = 0000000476a79067
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.0/0000:10:00.0/local_cpus
Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq ipv6 dm_mirror dm_region_hash dm_log dm_mod e1000e i2c_i801 i2c_core iTCO_wdt igb sg pcspkr dca iTCO_vendor_support ext4 mbcache jbd2 sd_mod crc_t10dif lpfc mptsas scsi_transport_fc mptscsih mptbase scsi_tgt scsi_transport_sas [last unloaded: microcode]

Pid: 2997, comm: cat Not tainted 2.6.34-kk #32 SB/PRIMEQUEST 1800E
EIP: 0060:[<c05c82d5>] EFLAGS: 00010046 CPU: 19
EIP is at pci_user_read_config_dword+0x65/0xa0
EAX: 00000002 EBX: e44f1800 ECX: e144df14 EDX: 155668c7
ESI: 00000087 EDI: 00000000 EBP: e144df40 ESP: e144df0c
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process cat (pid: 2997, ti=e144c000 task=e26f2570 task.ti=e144c000)
Stack:
 c09ceac0 c0570f72 ffffffff 08c57000 00000000 00001000 e44f1800 c05d2404
<0> e144df40 00001000 00000000 00001000 08c57000 3093ae50 e420cb40 e358d5c0
<0> c05d2300 fffffffb c054984f e144df9c 00008000 08c57000 e358d5c0 00008000
Call Trace:
 [<c0570f72>] ? security_capable+0x22/0x30
 [<c05d2404>] ? proc_bus_pci_read+0x104/0x220
 [<c05d2300>] ? proc_bus_pci_read+0x0/0x220
 [<c054984f>] ? proc_reg_read+0x5f/0x90
 [<c05497f0>] ? proc_reg_read+0x0/0x90
 [<c050694d>] ? vfs_read+0x9d/0x190
 [<c04958f4>] ? audit_syscall_entry+0x204/0x230
 [<c0506a81>] ? sys_read+0x41/0x70
 [<c0402f1f>] ? sysenter_do_call+0x12/0x28
Code: b4 26 00 00 00 00 b8 20 88 b1 c0 c7 44 24 08 ff ff ff ff e8 3e 52 22 00 f6 83 24 04 00 00 20 75 34 8b 43 08 8d 4c 24 08 8b 53 1c <8b> 70 40 89 4c 24 04 89 f9 c7 04 24 04 00 00 00 ff 16 89 c6 f0
EIP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0 SS:ESP 0068:e144df0c
CR2: 0000000000000042
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>