Previously pcie_device_init() called get_device() if device_register() for
the new pcie_device succeeded, and remove_iter() called put_device() when
removing before unregistering the device.

But device_register() already increments the reference count in
device_add(), so we don't need to do it again here.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This is required so that we give up the last reference to the device.
Removed the kfree() as put_device will result in release_pcie_device()
being called and hence the container of the device will be kfree'd.

[bhelgaas: fix conflict after my previous cleanup]
Signed-off-by: NLevente Kurusa <levex@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Make the straightline path the normal no-error path.  Check for errors and
return them directly, instead of checking for success and putting the
normal path in an "if" body.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The pcie_portdrv .probe() method calls pci_enable_device() once, in
pcie_port_device_register(), but the .remove() method calls
pci_disable_device() twice, in pcie_port_device_remove() and in
pcie_portdrv_remove().

That causes a "disabling already-disabled device" warning when removing a
PCIe port device.  This happens all the time when removing Thunderbolt
devices, but is also easy to reproduce with, e.g.,
"echo 0000:00:1c.3 > /sys/bus/pci/drivers/pcieport/unbind"

This patch removes the disable from pcie_portdrv_remove().

[bhelgaas: changelog, tag for stable]
Reported-by: NDavid Bulkow <David.Bulkow@stratus.com>
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v2.6.32+

This patch enhances the type safety for the kfifo API.  It is now safe
to put const data into a non const FIFO and the API will now generate a
compiler warning when reading from the fifo where the destination
address is pointing to a const variable.

As a side effect the kfifo_put() does now expect the value of an element
instead a pointer to the element.  This was suggested Russell King.  It
make the handling of the kfifo_put easier since there is no need to
create a helper variable for getting the address of a pointer or to pass
integers of different sizes.

IMHO the API break is okay, since there are currently only six users of
kfifo_put().

The code is also cleaner by kicking out the "if (0)" expressions.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NStefani Seibold <stefani@seibold.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix whitespace, capitalization, and spelling errors.  No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.

Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus())
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The pcie_ports parameter, which defaults to 'auto', allows a user
to specify if PCIe port services are disabled ('compat'), always
enabled ('native'), or only used when allowed by the BIOS
('auto').

Where CONFIG_ACPI isn't enabled, as is often the case for non
x86/ia64 platforms, the 'auto' behavior results in that of
'compat'. Thus in order to use port services on these platforms
'pcie_ports=native' must be added to the kernel command line.

This patch results in the 'native' behavior being followed where
'auto' is selected and ACPI is not enabled.
Signed-off-by: NAndrew Murray <amurray@embedded-bits.co.uk>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

One PCI bus reset function to rule them all.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Convert pciehp to be builtin only, with no module option.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

The previous option title "PCI Express support" is confusing.  The name
seems to imply this option is required to get PCIe support, which is not
true.

Fix it to "PCI Express Port Bus support" which is more accurate.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Fix trivial comment typo for pcie_pme_remove().
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When a PCIe device reports a fatal error, we reset the link leading
to it.  Previously we only did this for devices below Downstream Ports,
not for devices directly below Root Ports.

This patch changes that so we reset the link leading to devices below
Root Ports just like we do for those below Downstream Ports.

[bhelgaas: changelog, keep dev_printk(KERN_DEBUG)]
Signed-off-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The function aer_recover_queue() is a public interface and the
severity argument uses #defines that are in the private header
pci/pcie/aer/aerdrv.h.

This patch moves the #defines from pci/pcie/aer/aerdrv.h to
include/linux/aer.h.

[bhelgaas: split "remove 'extern' from declarations" to another patch]
Signed-off-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Previously, we always updated info->firmware_first, even for HEST entries
that didn't match the device.  Therefore, if the last HEST descriptor was
a PCIe structure that didn't match the device, we always cleared
dev->__aer_firmware_first.
Tested-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This factors out the matching of HEST structure type and PCIe device type
to improve readability.  No functional change.
Tested-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

AER is a PCIe-only capability, so there's no point in trying to match
a HEST PCIe structure with a non-PCIe device.

Previously, a HEST global AER bridge entry (type 8) could incorrectly
match *any* bridge, even a legacy PCI-PCI bridge, and a non-global
HEST entry could match a legacy PCI device.
Tested-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The following warning was seen on 3.9 when a corrected PCIe error was being
handled by the AER subsystem.

WARNING: at .../drivers/pci/search.c:214 pci_get_dev_by_id+0x8a/0x90()

This occurred because a call to pci_get_domain_bus_and_slot() was added to
cper_print_pcie() to setup for the call to cper_print_aer().  The warning
showed up because cper_print_pcie() is called in an interrupt context and
pci_get* functions are not supposed to be called in that context.

The solution is to move the cper_print_aer() call out of the interrupt
context and into aer_recover_work_func() to avoid any warnings when calling
pci_get* functions.
Signed-off-by: NLance Ortiz <lance.ortiz@hp.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Fix kerneldoc for pci_disable_link_state().

[bhelgaas: expand comment, fix typos]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some devices have hardware problems related to using ASPM.  Drivers for
these devices use pci_disable_link_state() to prevent their device from
entering L0s or L1.  But on platforms where the OS doesn't have permission
to manage ASPM, pci_disable_link_state() doesn't actually disable ASPM.

Windows has a similar mechanism ("PciASPMOptOut"), and when the OS doesn't
have control of ASPM, it doesn't actually disable ASPM either.

This patch just adds a warning in dmesg about the fact that
pci_disable_link_state() is doing nothing.
Reported-by: NEmmanuel Grumbach <egrumbach@gmail.com>
Reference: https://lkml.kernel.org/r/CANUX_P3F5YhbZX3WGU-j1AGpbXb_T9Bis2ErhvKkFMtDvzatVQ@mail.gmail.com
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57331Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We had an inconsistent mix of using and omitting the "extern" keyword
on function declarations in header files.  This removes them all.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

PCIe PME doesn't depend on ACPI, so remove the #includes and
Kconfig dependency.
Based-on-patch-by: NAndrew Murray <Andrew.Murray@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This fixes "set but not used" warnings found via "make W=1".
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This fixes "no previous prototype" warnings found via "make W=1".
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This fixes a "no previous prototype" warning for pcie_port_acpi_setup()
found via "make W=1".

[bhelgaas: changelog]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Currently the aer_inject driver returns -ENOTTY when the target PCIe
device root port is not found or if the device or root port doesn't
support AER.

In the case where the root port isn't found, the driver should return
-ENODEV, and in the other cases it should return -EPERM.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The runtime PM of PCIe ports turns out to be quite fragile, as in
some cases things work while in some other cases they don't and we
don't seem to have a good way to determine whether or not they are
going to work in advance.

For this reason, avoid enabling runtime PM for PCIe ports by
keeping their runtime PM reference counters always above 0 for the
time being.

When a PCIe port is suspended, it can no longer report events like
hotplug, so hotplug below the port may not work, as in the bug
report below.

[bhelgaas: changelog, stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=53811Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.6+

Change to remove local PCI_BUS() define and use the new PCI_BUS_NUM()
interface from PCI.
Signed-off-by: NShuah Khan <shuah.khan@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJoerg Roedel <joro@8bytes.org>

Don't allocate and track PCIe ASPM state when "pcie_aspm=off" is specified
on the kernel command line.

Based-on-patch-from: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDavid Bulkow <david.bulkow@stratus.com>
Acked-by: NMyron Stowe <myron.stowe@redhat.com>

On PCI bus hotplug removal, pcie_aspm_exit_link_state() can potentially
skip parent devices that have link_state allocated.  Instead of exiting
early if a given device is not PCIe, check whether or not the device's
parent has link_state allocated.  This enables pcie_aspm_exit_link_state()
to properly clean up parent link_state when the last function in a slot
might not be PCIe.
Reported-by: NJoe Lawrence <joe.lawrence@stratus.com>
Tested-by: NJoe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use PCI Express Capability access functions to simplify device
Capabilities Register usages.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
ASPM is unsupported.  However, the semantics of force should probably allow
for this, especially as they did before 3c076351 ("PCI: Rework ASPM
disable code")

This patch just skips the clearing of any ASPM setup that the firmware has
carried out on this bus if pcie_aspm=force is being used.

Reference: http://bugs.launchpad.net/bugs/962038Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org

The function aer_recover_queue() calls pci_get_domain_bus_and_slot(), which
requires that the caller decrement the reference count with pci_dev_put().
This patch adds the missing call to pci_dev_put().
Signed-off-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NShuah Khan <shuah.khan@hp.com>
CC: stable@vger.kernel.org

These changes make cper_print_aer more consistent with aer_print_error
and clean things up by elimiating the use of the prefix variable and
replacing it with dev_printk.
Signed-off-by: NLance Ortiz <lance.ortiz@hp.com>
Acked-by: NBoris Petkov <bp@alien8.de>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch will provide a more reliable and easy way for user-space
applications to have access to AER logs rather than reading them from the
message buffer. It also provides a way to notify user-space when an AER
event occurs.

The aer driver is updated to generate a trace event of function 'aer_event'
when a PCIe error is reported over the AER interface.  The trace event was
added to both the interrupt based aer path and the firmware first path.
Signed-off-by: NLance Ortiz <lance.ortiz@hp.com>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NBoris Petkov <bp@alien8.de>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Ulrich reported that his USB3 cardreader does not work reliably when
connected to the USB3 port.  It turns out that USB3 controller failed to
awaken when plugging in the USB3 cardreader.  Further experiments found
that the USB3 host controller can only be awakened via polling, not via PME
interrupt.  But if the PCIe port to which the USB3 host controller is
connected is suspended, we cannot poll the controller because its config
space is not accessible when the PCIe port is in a low power state.

To solve the issue, the PCIe port will not be suspended if any subordinate
device needs PME polling.

[bhelgaas: use bool consistently rather than mixing int/bool]
Reference: http://lkml.kernel.org/r/50841CCC.9030809@uli-eckhardt.deReported-by: NUlrich Eckhardt <usb@uli-eckhardt.de>
Tested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org	# v3.6+

Add standard #defines for ASPM fields in PCI Express Link Capability and
Link Control registers.

Previously we used PCIE_LINK_STATE_L0S and PCIE_LINK_STATE_L1 directly, but
these are defined for the Linux ASPM interfaces, e.g.,
pci_disable_link_state(), and only coincidentally match the actual register
bits.  PCIE_LINK_STATE_CLKPM, also part of that interface, does not match
the register bit.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>

Use PCI Express Capability access functions to simplify portdrv.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

CONFIG_HOTPLUG is going away as an option so __devexit_p, __devint,
__devinitdata, __devinitconst, and _devexit are no longer needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When an error is detected on a PCIe device which does not have an
AER-aware driver, prevent AER infrastructure from reporting
successful error recovery.

This is because the report_error_detected() function that gets
called in the first phase of recovery process allows forward
progress even when the driver for the device does not have AER
capabilities. It seems that all callbacks (in pci_error_handlers
structure) registered by drivers that gets called during error
recovery are not mandatory. So the intention of the infrastructure
design seems to be to allow forward progress even when a specific
callback has not been registered by a driver. However, if error
handler structure itself has not been registered, it doesn't make
sense to allow forward progress.

As a result of the current design, in the case of a single device
having an AER-unaware driver or in the case of any function in a
multi-function card having an AER-unaware driver, a successful
recovery is reported.

Typical scenario this happens is when a PCI device is detached
from a KVM host and the pci-stub driver on the host claims the
device. The pci-stub driver does not have error handling capabilities
but the AER infrastructure still reports that the device recovered
successfully.

The changes proposed here leaves the device(s)in an unrecovered state
if the driver for the device or for any device in the subtree
does not have error handler structure registered. This reflects
the true state of the device and prevents any partial recovery (or no
recovery at all) reported as successful.

[bhelgaas: changelog]
Signed-off-by: NVijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLinas Vepstas <linasvepstas@gmail.com>
Reviewed-by: NMyron Stowe <myron.stowe@redhat.com>