The functions link_state_store() and clk_ctl_store() had just subtracted
ASCII '0' from input which could lead to undesired results.  Instead, use
Linux string functions to safely parse input.

[bhelgaas: check kstrtouint() return value]
Signed-off-by: NChris J Arges <chris.j.arges@canonical.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Support for keyword 'boolean' will be dropped later on.

No functional change.

Reference: http://lkml.kernel.org/r/cover.1418003065.git.cj@linux.comSigned-off-by: NChristoph Jaeger <cj@linux.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

After commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM in the PCI core code.
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If the irqchip handling the PCIe PME interrupt is not able
to enable interrupt wakeup we should properly reflect this
in the PME suspend status.

This fixes a kernel warning on resume, where it would try
to disable the irq wakeup that failed to be activated while
suspending, for example:

WARNING: CPU: 0 PID: 609 at kernel/irq/manage.c:536 irq_set_irq_wake+0xc0/0xf8()
Unbalanced IRQ 384 wake disable

Fixes: 76cde7e4 (PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle)
Reported-and-tested-by: NRichard Zhu <richard.zhu@freescale.com>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add strings for all AER error bits defined in PCIe r3.0.

[bhelgaas: changelog, drop designated initializer change]
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Since commit de7d5f72 ("PCI/PM: Disable runtime PM of PCIe ports") the
runtime PM support code for PCIe ports in portdrv_pci.c has never been
used, so drop it entirely.

If we are to support runtime PM of PCIe ports, it will have to be done in a
different way most likely anyway.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

To make PCIe PME interrupts wake up the system from suspend to idle,
make the PME driver use enable_irq_wake() on the IRQ during system
suspend (if there are any wakeup devices below the given PCIe port)
without disabling PME interrupts.  This way, an interrupt will still
trigger if a wakeup event happens and the system will be woken up (or
system suspend in progress will be aborted) by means of the new
mechanics introduced previously.

This change allows Wake-on-LAN to be used for wakeup from
suspend-to-idle on my MSI Wind tesbed netbook.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

For hot-added PCIe ports on x86 platforms, we always warned about an
invalid IRQ, e.g.,

  pci 0000:00:00.0: device [8086:0e0b] has invalid IRQ; check vendor BIOS

This was because we check pci_dev->irq before actually allocating the IRQ
for the device, which happens in this path:

  pcie_port_device_register
    pci_enable_device
      pci_enable_device_flags
        do_pci_enable_device
          pcibios_enable_device    (on x86)
            pcibios_enable_irq

This warning message isn't generated for PCIe ports present at boot time
because x86 arch code has called acpi_pci_irq_enable() in pci_acpi_init()
for each PCI device for safety.

[bhelgaas: changelog]
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

AER uses a separate trace interface by now. To make it
consistent, move it into unified RAS trace interface.
Signed-off-by: NChen, Gong <gong.chen@linux.intel.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Merge quoted strings that are broken across lines into a single entity.
The compiler merges them anyway, but checkpatch complains about it, and
merging them makes it easier to grep for strings.

No functional change.

[bhelgaas: changelog, do the same for everything under drivers/pci]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Fix various whitespace errors.

No functional change.

[bhelgaas: fix other similar problems]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Today the PCIe port bus driver disables the Hot-plug service if the port
device does not have the capability to generate interrupts.  However, a
user must be able to use the "pciehp_poll_mode" parameter to use the pciehp
in polling method in such a case.  Today it is not possible.

This patch allows a hotplug service driver to decide whether or not it
would like to continue in the absence of interrupts.
Signed-off-by: NRajat Jain <rajatxjain@gmail.com>
Signed-off-by: NRajat Jain <rajatjain@juniper.net>
Signed-off-by: NGuenter Roeck <groeck@juniper.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers using these two
interfaces need to be updated to use the new pci_enable_msi_range()  or
pci_enable_msi_exact() and pci_enable_msix_range() or
pci_enable_msix_exact() interfaces.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

In the discussion for this set of patches [link below], Bjorn Helgaas
pointed out that the ACPI HEST AER error sources do not have the PCIe
segment number associated with the bus.  I worked with the ACPI spec and
got this change to definition of the "Bus" field into the recently released
ACPI Spec 5.0a section 18.3.2.3-5:

  Identifies the PCI Bus and Segment of the device.  The Bus is encoded in
  bits 0-7.  For systems that expose multiple PCI segment groups, the
  segment number is encoded in bits 8-23 and bits 24-31 must be zero.  For
  systems that do not expose multiple PCI segment groups, bits 8-31 must be
  zero.  If the GLOBAL flag is specified, this field is ignored.

This patch makes use of the new definition in the only place in the kernel
that uses the acpi_hest_aer_common's bus field.

This depends on 36f36151 ("ACPICA: Add helper macros to extract
bus/segment numbers from HEST table.")

Link: http://lkml.kernel.org/r/1370542251-27387-1-git-send-email-betty.dall@hp.comSigned-off-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

My philosophy is unused code is dead code.  And dead code is subject to bit
rot and is a likely source of bugs.  Use it or lose it.

This reverts part of 3e1b1600 ("ACPI/PCI: PCIe ASPM _OSC support
capabilities called when root bridge added"), removing this interface:

    pcie_aspm_enabled()

[bhelgaas: split to separate patch]
Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Andrew Patterson <andrew.patterson@hp.com>

This creates an MSI-X counterpart for pci_msi_vec_count().  Device drivers
can use this function to obtain maximum number of MSI-X interrupts the
device supports and use that number in a subsequent call to
pci_enable_msix().

pci_msix_vec_count() supersedes pci_msix_table_size() and returns a
negative errno if device does not support MSI-X interrupts.  After this
update, callers must always check the returned value.

The only user of pci_msix_table_size() was the PCI-Express port driver,
which is also updated by this change.
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NTejun Heo <tj@kernel.org>

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>

aer_hest_parse() and aer_hest_parse_aff() are almost identical.  We use
aer_hest_parse() to check the ACPI_HEST_FIRMWARE_FIRST flag for a specific
device, and we use aer_hest_parse_aff() to check to see if any device sets
the flag.

This drops aer_hest_parse_aff() and enhances aer_hest_parse() so it
collects the union of the PCIe ACPI_HEST_FIRMWARE_FIRST flag settings when
no specific device is supplied.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NBetty Dall <betty.dall@hp.com>

aer_set_firmware_first() searches the HEST for an error source descriptor
matching the specified PCI device.  It uses the apei_hest_parse() iterator
to call aer_hest_parse() for every descriptor in the HEST.

Previously, aer_hest_parse() incorrectly assumed every descriptor was for a
PCIe error source.  This patch adds a check to avoid that error.

[bhelgaas: factor check into helper, use in aer_hest_parse_aff(), changelog]
Signed-off-by: NBetty Dall <betty.dall@hp.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Save one indentation level in aer_print_error() for the generic case where
we have info->status of an error, disregard 80 cols rule a bit for the sake
of better readability, fix alignment.

No functionality change.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

... and call it instead of duplicating the large printk format
statement.

No functionality change.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

device_driver.name is "const char *"
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
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>