* pci/betty-aer-v3:
  PCI/AER: Reset link for devices below Root Port or Downstream Port
  ACPI / APEI: Force fatal AER severity when component has been reset
  PCI/AER: Remove "extern" from function declarations
  PCI/AER: Move AER severity defines to aer.h
  PCI/AER: Set dev->__aer_firmware_first only for matching devices
  PCI/AER: Factor out HEST device type matching
  PCI/AER: Don't parse HEST table for non-PCIe devices

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: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The CPER error record has a reset bit that indicates that the platform
has reset the component. The reset bit can be set for any severity
error including recoverable.  From the AER code path's perspective,
any error is fatal if the component has been reset.  This patch
upgrades the severity of the AER recovery to AER_FATAL whenever the
CPER error record indicates that the component has been reset.

[bhelgaas: s/bus has been reset/component has been reset/]
Signed-off-by: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn 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.

[bhelgaas: split out from "move AER severity defines" patch]
Signed-off-by: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn 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: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn 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: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn 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: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn 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: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

* pci/jiang-iov-fixes:
  PCI: Hide remove and rescan sysfs interfaces for SR-IOV virtual functions
  PCI: Finish SR-IOV VF setup before adding the device

PCI devices for SR-IOV virtual functions should only be created/
destroyed by pci_enable_sriov()/pci_disable_sriov() because special
data structures are associated with SR-IOV virtual functions.
So hide hotplug related sysfs interfaces "remove" and "rescan" for
SR-IOV virtual functions, otherwise it may cause memory leakage
and other issues.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Donald Dutile <ddutile@redhat.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ram Pai <linuxram@us.ibm.com>

* pci/alexander-msi:
  x86/MSI: Conserve interrupt resources when using multiple-MSIs
  PCI: Allocate only as many MSI vectors as requested by driver

* pci/shane-amd-ahci-i2c:
  i2c-piix4: Add AMD CZ SMBus device ID
  ahci: Add AMD CZ SATA device ID
  PCI: Put Hudson-2 device IDs together

Current multiple-MSI implementation does not take into account actual
number of requested MSIs and always rounds that number to a larger
power-of-two value.  Yet, the number of MSIs a PCI device could send (and
therefore the number of messages a device driver could request) may be
smaller.  As result, resources allocated for extra MSIs are just wasted.

This update takes advantage of 'msi_desc::nvec_used' field introduced with
generic MSI code to track the number of requested and used MSIs.  As
result, resources associated with interrupts are conserved.  Of those
resources most noticeable are x86 interrupt vectors.

The initial version of this fix also conserved IRTEs, but Jan noticed that
a malfunctioning PCI device might send a message number it did not claim
and thus refer to an IRTE it does not own.  To avoid this security hole,
as many IRTEs are reserved as the device could possibly send.

[bhelgaas: changelog, rename to "nvec_used"]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

* pci/jiang-remove-global-list:
  PCI/ACPI: Use dev_printk(), acpi_handle_print(), pr_xxx() when possible
  PCI/ACPI: Remove unused global list acpi_pci_roots
  PCI/ACPI: Introduce "handle" local for economy of expression
  PCI/ACPI: Combine duplicate adjacent "if" tests

To add AMD CZ SMBus controller device ID.

[bhelgaas: drop pci_ids.h update]
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@vger.kernel.org

To add AMD CZ SATA controller device ID of IDE mode.

[bhelgaas: drop pci_ids.h update]
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

To put all AMD Hudson-2 device IDs together for better maintenance.

[bhelgaas: also sort Hudson-2 devices by ID]
Signed-off-by: Shane Huang <shane.huang@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Acked-by: Jean Delvare <khali@linux-fr.org>

* pci/misc:
  PCI: Replace strict_strtoul() with kstrtoul()
  PCI: Fix comment typo for PCI_EXP_LNKCAP_CLKPM
  PCI: Replace printks with appropriate pr_*()
  PCI: Fix kerneldoc for pci_disable_link_state()
  x86/PCI: Increase info->res_num before checking pci_use_crs
  PCI: Fix INTC comment typo for pci_swizzle_interrupt_pin()
  PCI: Convert ioapic.c to module_pci_driver

The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete.  Thus, kstrtoul() should be
used.

[bhelgaas: "#define strict_strtoul  kstrtoul", so no functional change]
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Commit 4f535093 "PCI: Put pci_dev in device tree as early as possible"
moves device registering from pci_bus_add_devices() to pci_device_add().
That causes problems for virtual functions because device_add(&virtfn->dev)
is called before setting the virtfn->is_virtfn flag, which then causes Xen
to report PCI virtual functions as PCI physical functions.

Fix it by setting virtfn->is_virtfn before calling pci_device_add().

[Jiang Liu]: Move the setting of virtfn->is_virtfn ahead further for better
readability and modify changelog.
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org	# v3.9+

Fix trivial typo for PCI_EXP_LNKCAP_CLKPM comment.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Use dev_printk(), acpi_handle_print(), and pr_xxx() to print messages
in pci_root.c.

[bhelgaas: fold in dev_printk() changes, use dev_printk() in
handle_root_bridge_insertion()]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Len Brown <lenb@kernel.org>

Now the global list acpi_pci_roots pci_root.c is useless, remove it.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Len Brown <lenb@kernel.org>

[bhelgaas: split out from acpi_handle_printk() changes]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

[bhelgaas: split out from acpi_pci_roots removal]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Because of the encoding of the "Multiple Message Capable" and "Multiple
Message Enable" fields, a device can only advertise that it's capable of a
power-of-two number of vectors, and the OS can only enable a power-of-two
number.

For example, a device that's limited internally to using 18 vectors would
have to advertise that it's capable of 32.  The 14 extra vectors consume
vector numbers and IRQ descriptors even though the device can't actually
use them.

This fix introduces a 'msi_desc::nvec_used' field to address this issue.
When non-zero, it is the actual number of MSIs the device will send, as
requested by the device driver.  This value should be used by architectures
to set up and tear down only as many interrupt resources as the device will
actually use.

Note, although the existing 'msi_desc::multiple' field might seem
redundant, in fact it is not.  The number of MSIs advertised need not be
the smallest power-of-two larger than the number of MSIs the device will
send.  Thus, it is not always possible to derive the former from the
latter, so we need to keep them both to handle this case.

[bhelgaas: changelog, rename to "nvec_used"]
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Replace deprecated printk(KERN_ERR...) with pr_err() in pci-acpi.c
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Fix kerneldoc for pci_disable_link_state().

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

We should increase info->res_num before we checking pci_use_crs return
when pci=nocrs set.

No functional change, since we don't use res_num and res_offset[]
in the "!pci_use_crs" case anyway, but this makes the code read better.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Feng Tang <feng.tang@intel.com>

The INTx pin should be INIT[ABCD].  Fix the typo "3=INTC".
Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Use module_pci_driver instead of init/exit, make code clean.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

* pci/kevin-bus-to-resource:
  PCI: Unset resource if initial BAR value is invalid
  PCI: Consolidate calls to pcibios_bus_to_resource() in __pci_read_base()
  PCI: Add 0x prefix to BAR register position in __pci_read_base()

The initial BAR value in the following example is invalid:

  pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff] (bus address [0xe0000000-0xffffffff])
  pci 0000:01:00.0: reg 10: initial BAR value: 0xa0000000
  pci 0000:01:00.0: reg 10: [mem 0xa0000000-0xa000007f 64bit]

bus_to_resource(0xa0000000) yields 0xa0000000 because there's no host
bridge window whose bus address range contains 0xa0000000.  But CPU
accesses to 0xa0000000 appear on the bus at 0xe0000000, so they will
not be claimed if the BAR contains 0xa0000000.

If we find a BAR where resource_to_bus(bus_to_resource(A)) != A, we can
work around this problem by reassigning the BAR.

[bhelgaas: changelog, comment]
Reference: https://lkml.kernel.org/r/1368536876-27307-3-git-send-email-haokexin@gmail.comSigned-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Since we will invoke pcibios_bus_to_resource() unconditionally if we
don't goto fail, move it out of if/else wrap.  No function change.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

We print the BAR register's position in hexadecimal format, so it
is more readable if 0x prefix is added.

[bhelgaas: keep dev_printk(), not dev_dbg(), so this is always in dmesg]
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

* pci/misc:
  PCI/ASPM: Warn when driver asks to disable ASPM, but we can't do it
  sparc/PCI: Use PCI_UNKNOWN for unknown power state
  powerpc/PCI: Use PCI_UNKNOWN for unknown power state
  PCI/ACPI: Check acpi_resource_to_address64() return value
  PCI: Work around Ivytown NTB BAR size issue

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: Emmanuel 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: Bjorn Helgaas <bhelgaas@google.com>

Previously we initialized dev->current_state to 4 (PCI_D3cold), but I think
we wanted PCI_UNKNOWN (5) here based on the comment and the fact that the
generic version of this code, pci_setup_device(), uses PCI_UNKNOWN.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: David S. Miller <davem@davemloft.net>

Previously we initialized dev->current_state to 4 (PCI_D3cold), but I think
we wanted PCI_UNKNOWN (5) here based on the comment and the fact that the
generic version of this code, pci_setup_device(), uses PCI_UNKNOWN.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

We should check the acpi_resource_to_address64() return value, which
also removes the need to validate the resource type beforehand.
No functional change.

Found by Coverity (CID 113815).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>