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>

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>

The aspm code will currently set the configured aspm policy before drivers
have had an opportunity to indicate that their hardware doesn't support it.
Unfortunately, putting some hardware in L0 or L1 can result in the hardware
no longer responding to any requests, even after aspm is disabled. It makes
more sense to leave aspm policy at the BIOS defaults at initial setup time,
reconfiguring it after pci_enable_device() is called. This allows the
driver to blacklist individual devices beforehand.
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Some compiler generates following warnings:

  In function 'aer_isr':
  warning: 'e_src.id' may be used uninitialized in this function
  warning: 'e_src.status' may be used uninitialized in this function

Avoid status flag "int ret" and return constants instead, so that
gcc sees the return value matching "it is initialized" better.
Acked-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

One of the arguments during the suspend blockers discussion was that
the mainline kernel didn't contain any mechanisms making it possible
to avoid races between wakeup and system suspend.

Generally, there are two problems in that area.  First, if a wakeup
event occurs exactly when /sys/power/state is being written to, it
may be delivered to user space right before the freezer kicks in, so
the user space consumer of the event may not be able to process it
before the system is suspended.  Second, if a wakeup event occurs
after user space has been frozen, it is not generally guaranteed that
the ongoing transition of the system into a sleep state will be
aborted.

To address these issues introduce a new global sysfs attribute,
/sys/power/wakeup_count, associated with a running counter of wakeup
events and three helper functions, pm_stay_awake(), pm_relax(), and
pm_wakeup_event(), that may be used by kernel subsystems to control
the behavior of this attribute and to request the PM core to abort
system transitions into a sleep state already in progress.

The /sys/power/wakeup_count file may be read from or written to by
user space.  Reads will always succeed (unless interrupted by a
signal) and return the current value of the wakeup events counter.
Writes, however, will only succeed if the written number is equal to
the current value of the wakeup events counter.  If a write is
successful, it will cause the kernel to save the current value of the
wakeup events counter and to abort the subsequent system transition
into a sleep state if any wakeup events are reported after the write
has returned.

[The assumption is that before writing to /sys/power/state user space
will first read from /sys/power/wakeup_count.  Next, user space
consumers of wakeup events will have a chance to acknowledge or
veto the upcoming system transition to a sleep state.  Finally, if
the transition is allowed to proceed, /sys/power/wakeup_count will
be written to and if that succeeds, /sys/power/state will be written
to as well.  Still, if any wakeup events are reported to the PM core
by kernel subsystems after that point, the transition will be
aborted.]

Additionally, put a wakeup events counter into struct dev_pm_info and
make these per-device wakeup event counters available via sysfs,
so that it's possible to check the activity of various wakeup event
sources within the kernel.

To illustrate how subsystems can use pm_wakeup_event(), make the
low-level PCI runtime PM wakeup-handling code use it.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Acked-by: Nmarkgross <markgross@thegnar.org>
Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>

Commit c7f48656
(PCI PM: PCIe PME root port service driver) causes the native PCIe
PME signaling to be used by default, if the BIOS allows the kernel to
control the standard configuration registers of PCIe root ports.
However, the native PCIe PME is coupled to the native PCIe hotplug
and calling pcie_pme_acpi_setup() makes some BIOSes expect that
the native PCIe hotplug will be used as well.  That, in turn, causes
problems to appear on systems where the PCIe hotplug driver is not
loaded.  The usual symptom, as reported by Jaroslav Kameník and
others, is that the ACPI GPE associated with PCIe hotplug keeps
firing continuously causing kacpid to take substantial percentage
of CPU time.

To work around this issue, change the default so that the native
PCIe PME signaling is only used if directly requested with the help
of the pcie_pme= command line switch.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15924 , which is
a listed regression from 2.6.33.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NJaroslav Kameník <jaroslav@kamenik.cz>
Tested-by: NAntoni Grzymala <antekgrzymala@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Now, a dedicated HEST tabling parsing code is used for PCIE AER
firmware_first setup. It is rebased on general HEST tabling parsing
code of APEI. The firmware_first setup code is moved from PCI core to
AER driver too, because it is only AER related.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Style cleanup for pci_{en,dis}able_pcie_error_reporting().
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Skip zero-ing in aer_alloc_rpc() since it is allocated by kzalloc().
The closing comment marker "*/" is recommended for kernel-doc comments.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

I noticed that when I inject a fatal error to an endpoint via
aer-inject, aer_root_reset() is called as reset_link for a
downstream port at upstream of the endpoint:

  pcieport 0000:00:06.0: AER: Uncorrected (Fatal) error received: id=5401
   :
  pcieport 0000:52:02.0: Root Port link has been reset

It externally appears to be working, but internally issues some
accesses to PCI_ERR_ROOT_COMMAND/STATUS registers that is for
root port so not available on downstream port.

This patch introduces default_downstream_reset_link that is
a version of aer_root_reset() with no accesses to root port's
register. It is used for downstream ports that has no reset_link
function its specific.

This patch also updates related description in pcieaer-howto.txt.
Some minor fixes are included.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The structure find_aer_service_data is no longer useful.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reviewed-by: NJin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The pcie->port of port service device points the port associated
the service with.  The find_aer_service iterates over children of
given port udev.

So it is clear that the pcie->port of port service of given port
udev must always point the udev.

Therefore we can know the type of udev without checking its children.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Make it clear that we only interest in 2 *_RCV bits.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The Error Source Identification Register (Offset 34h) is 4 byte
which contains a couple of 2 byte field, "[15:0] ERR_COR Source
Identification" and "[31:16] ERR_FATAL/NONFATAL Source Identification."

This patch defines PCI_ERR_ROOT_ERR_SRC to make dword access sensible.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Move dev_printks for debug into do_recovery().
This allows do_recovery() to return void.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Current get_e_source() returns pointer to an element of array.
However since it also progress consume counter, it is possible
that the element is overwritten by newly produced data before
the element is really consumed.

This patch changes get_e_source() to copy contents of the element
to address pointed by its caller.  Once copied the element in
array can be consumed.

And relocate this function to more innocuous place.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Divide tricky for-loop into readable if-blocks.

The logic to set multi_error_valid (to force walking pci bus
hierarchy to find 2nd~ error devices) is changed too, to check
MULTI_{,_UN}COR_RCV bit individually and to force walk only when
it is required.

And rework setting e_info->severity for uncorrectable, not to use
magic numbers.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Stop iteration if we cannot register any more.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Inline too-simple subroutine only used here.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Take core part of find_device_iter() to make a new function
is_error_source() that checks given device has report an error
or not.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Return bool to indicate that the source device is found or not.
This allows us to skip calling aer_process_err_devices() if we can.

And move dev_printk for debug into this function.

v2: return bool instead of int
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

These functions are only called from init/remove path of aerdrv,
so move them from aerdrv_core.c to aerdrv.c, to make them static.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This cleanup solves some minor naming issues by removing unuseful
function aer_delete_rootport() and by renaming disable_root_aer()
to aer_disable_rootport().

- Inconsistent location of alloc & free:
   The struct rpc is allocated in aer_alloc_rpc() at aerdrv.c
   while it is implicitly freed in aer_delete_rootport() at
   aerdrv_core.c.

- Inconsistent function name:
   It makes a bit confusion that aer_delete_rootport() is seemed
   to be paired with aer_enable_rootport(), i.e. there is neither
   "add" against "delete" nor "disable" against "enable".
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Handle preserved bits properly.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

While testing completion timeouts I found that hardware was not recovering.
It looks like the hot reset was never being propagated to the endpoint
devices on the bus due to the fact that we were clearing the bit too
quickly.

The documentation I have states that we should be transmitting hot reset
TS1s for 2ms.  To achieve this I have added a 2ms delay from the time we
set the secondary bus reset bit to the time we clear it.  In addition I
changed the define used for the secondary bus reset bit to match the
register define that was being used.
Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Set power.async_suspend for all PCI devices and PCIe port services,
so that they can be suspended and resumed in parallel with other
devices they don't depend on in a known way (i.e. devices which are
not their parents or children).

This only affects the "regular" suspend and resume stages, which
means in particular that the restoration of the PCI devices' standard
configuration registers during resume will still be carried out
synchronously (at the "early" resume stage).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Use pci_pcie_cap() instead of pci_find_capability() to get PCIe
capability offset. This reduces redundant search in PCI configuration
space.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Use pci_is_pcie() instead of looking at obsolete is_pcie field in
struct pci_dev.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Apparently, some machines may have problems with PCI run-time power
management if MSIs are used for the native PCIe PME signaling.  In
particular, on the MSI Wind U-100 PCIe PME interrupts are not
generated by a PCIe root port after a resume from suspend to RAM, if
the system wake-up was triggered by a PME from the device attached to
this port.  [It doesn't help to free the interrupt on suspend and
request it back on resume, even if that is done along with disabling
the MSI and re-enabling it, respectively.]  However, if INTx
interrupts are used for this purpose on the same machine, everything
works just fine.

For this reason, add a kernel command line switch allowing one to
request that MSIs be not used for the native PCIe PME signaling,
introduce a DMI table allowing us to blacklist machines that need
this switch to be set by default and put the MSI Wind U-100 into this
table.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

PCIe native PME detection mechanism is based on interrupts generated
by root ports or event collectors every time a PCIe device sends a
PME message upstream.

Once a PME message has been sent by an endpoint device and received
by its root port (or event collector in the case of root complex
integrated endpoints), the Requester ID from the message header is
registered in the root port's Root Status register.  At the same
time, the PME Status bit of the Root Status register is set to
indicate that there's a PME to handle.  If PCIe PME interrupt is
enabled for the root port, it generates an interrupt once the PME
Status has been set.  After receiving the interrupt, the kernel can
identify the PCIe device that generated the PME using the Requester
ID from the root port's Root Status register. [For details, see PCI
Express Base Specification, Rev. 2.0.]

Implement a driver for the PCIe PME root port service working in
accordance with the above description.

Based on a patch from Shaohua Li <shaohua.li@intel.com>.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The aer_inject module hangs in aer_inject() when checking the device's
error masks.  The hang is due to a recursive use of the aer_inject lock.
The aer_inject() routine grabs the lock while processing the error and then
calls pci_read_config_dword to read the masks. The pci_read_config_dword
routine is earlier overridden by pci_read_aer, which among other things,
grabs the aer_inject lock.

Fixed by moving the pci_read_config_dword calls to read the masks to before
the lock is taken.
Acked-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NAndrew Patterson <andrew.patterson@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The Correcteable/Uncorrectable Error Mask Registers are used by PCIe AER
driver which will controls the reporting of individual errors to PCIe RC
via PCIe error messages.

If hardware masks special error reporting to RC, the aer_inject driver
should not inject aer error.
Acked-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NYouquan, Song <youquan.song@intel.com>
Acked-by: NYing, Huang <ying.huang@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

If the BIOS does not export _OSC to allow OS take over the PCIe AER, the
pcie aer driver will not initialize the aer service. However, the
aer_inject driver does not check this scenario, which results in a kernel
oops when injecting an aer error into OS.  For example:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000350
IP: [<ffffffff812e08f7>] _spin_lock_irqsave+0xc/0x23
PGD 155c41067 PUD 157fe0067 PMD 0
Oops: 0002 [#1] SMP
Pid: 5119, comm: aer-inject Not tainted 2.6.32-rc8-mce #2
RIP: 0010:[<ffffffff812e08f7>]  [<ffffffff812e08f7>] _spin_lock_irqsave+0xc/0x23
RSP: 0018:ffff880157f81e28  EFLAGS: 00010096
RAX: 0000000000000296 RBX: 0000000000000000 RCX: 0000000000000100
RDX: 0000000000010000 RSI: 0000000000000246 RDI: 0000000000000350
RBP: ffff880157f81e28 R08: 0000000000000004 R09: ffff880157f81dac
R10: ffff88015a666f60 R11: ffff88015a666f40 R12: ffff88015758cc00
R13: 0000000000000350 R14: 0000000000000000 R15: 0000000000000100
FS:  00007f4d4a66e6f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000350 CR3: 000000015661a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process aer-inject (pid: 5119, threadinfo ffff880157f80000, task ffff8801585f4340)
Stack:
 ffff880157f81e78 ffffffff811b1615 ffff880157f81e78 ffffffff81222823
Call Trace:
 [<ffffffff811b1615>] aer_irq+0x38/0x117
 [<ffffffff81222823>] ? device_for_each_child+0x5f/0x6f
 [<ffffffffa00967bf>] aer_inject_write+0x409/0x45e [aer_inject]
 [<ffffffff810eb80e>] vfs_write+0xae/0x16a
 [<ffffffff810eb98e>] sys_write+0x47/0x6e
 [<ffffffff8100ba2b>] system_call_fastpath+0x16/0x1b
RIP  [<ffffffff812e08f7>] _spin_lock_irqsave+0xc/0x23
 RSP <ffff880157f81e28>
CR2: 0000000000000350

So check the _OSC before assuming that AER is available to the OS.
Signed-off-by: NYouquan, Song <youquan.song@intel.com>
Acked-by: NYing, Huang <ying.huang@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>