After 104daa71 ("PCI: Determine actual VPD size on first access"), the
PCI core computes the valid VPD size by parsing the VPD starting at offset
0x0.  We don't attempt to read past that valid size because that causes
some devices to crash.

However, some devices do have data past that valid size.  For example,
Chelsio adapters contain two VPD structures, and the driver needs both of
them.

Add pci_set_vpd_size().  If a driver knows it is safe to read past the end
of the VPD data structure at offset 0, it can use pci_set_vpd_size() to
allow access to as much data as it needs.

[bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and
return int (not ssize_t)]
Fixes: 104daa71 ("PCI: Determine actual VPD size on first access")
Tested-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We only support one flavor of VPD, so there's no need to complicate things
by having a "generic" struct pci_vpd and a more specific struct
pci_vpd_pci22.

Fold struct pci_vpd_pci22 directly into struct pci_vpd.

[bhelgaas: remove NULL check before kfree of dev->vpd (per kfreeaddr.cocci)]
Tested-by: NShane Seymour <shane.seymour@hpe.com>
Tested-by: NBabu Moger <babu.moger@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>

There's only one kind of VPD, so we don't need to qualify it as "the
version described by PCI spec rev 2.2."

Rename the following symbols to remove unnecessary "pci22":

  PCI_VPD_PCI22_SIZE	-> PCI_VPD_MAX_SIZE
  pci_vpd_pci22_size()	-> pci_vpd_size()
  pci_vpd_pci22_wait()	-> pci_vpd_wait()
  pci_vpd_pci22_read()	-> pci_vpd_read()
  pci_vpd_pci22_write()	-> pci_vpd_write()
  pci_vpd_pci22_ops	-> pci_vpd_ops
  pci_vpd_pci22_init()	-> pci_vpd_init()
Tested-by: NShane Seymour <shane.seymour@hpe.com>
Tested-by: NBabu Moger <babu.moger@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>

The struct pci_vpd_ops.release function pointer is always
pci_vpd_pci22_release(), so there's no need for the flexibility of a
function pointer.

Inline the pci_vpd_pci22_release() body into pci_vpd_release() and remove
pci_vpd_pci22_release() and the struct pci_vpd_ops.release function
pointer.
Tested-by: NShane Seymour <shane.seymour@hpe.com>
Tested-by: NBabu Moger <babu.moger@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>

Move pci_vpd_release() so it's next to the other VPD functions.  This puts
it next to pci_vpd_pci22_init(), which allocates the space freed by
pci_vpd_release().
Tested-by: NShane Seymour <shane.seymour@hpe.com>
Tested-by: NBabu Moger <babu.moger@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NHannes Reinecke <hare@suse.com>

The pci_platform_pm_ops structure is never modified, so declare it as
const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

4a7cc831 ("genirq/MSI: Move msi_list from struct pci_dev to struct
device") removed the contents of pci_msi_init_pci_dev().  All
implementation of it are now empty, so remove it completely.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit b3a72384 ("ARM/PCI: Replace pci_sys_data->align_resource with
global function pointer") introduced an ARM-specific align_resource()
function pointer.  This is not portable to other arches and doesn't work
for platforms with two different PCIe host bridge controllers.

Move the function pointer to the pci_host_bridge structure so each host
bridge driver can specify its own align_resource() function.
Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>

Add support for devices using Enhanced Allocation entries instead of BARs.
This allows the kernel to parse the EA Extended Capability structure in PCI
config space and claim the BAR-equivalent resources.

See https://pcisig.com/sites/default/files/specification_documents/ECN_Enhanced_Allocation_23_Oct_2014_Final.pdf

[bhelgaas: add spec URL, s/pci_ea_set_flags/pci_ea_flags/, consolidate
declarations, print unknown property in hex to match spec]
Signed-off-by: NSean O. Stalley <sean.stalley@intel.com>
[david.daney@cavium.com: Add more support/checking for Entry Properties,
allow EA behind bridges, rewrite some error messages.]
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit bac2a909 (PCI / PM: Avoid resuming PCI devices during
system suspend) introduced a mechanism by which some PCI devices that
were runtime-suspended at the system suspend time might be left in
that state for the duration of the system suspend-resume cycle.
However, it overlooked devices that were marked as capable of waking
up the system just because PME support was detected in their PCI
config space.

Namely, in that case, device_can_wakeup(dev) returns 'true' for the
device and if the device is not configured for system wakeup,
device_may_wakeup(dev) returns 'false' and it will be resumed during
system suspend even though configuring it for system wakeup may not
really make sense at all.

To avoid this problem, simply disable PME for PCI devices that have
not been configured for system wakeup and are runtime-suspended at
the system suspend time for the duration of the suspend-resume cycle.

If the device is in D3cold, its config space is not available and it
shouldn't be written to, but that's only possible if the device
has platform PM support and the platform code is responsible for
checking whether or not the device's configuration is suitable for
system suspend in that case.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some quirks search for a HyperTransport capability and use a hard-coded TTL
value of 48 to avoid an infinite loop.

Move the definition of PCI_FIND_CAP_TTL to pci.h and use it instead of the
hard-coded TTL values.

[bhelgaas: changelog]
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

pci_ari_enabled() is useful outside of drivers/pci, particularly for
deriving INTx routing via ACPI _PRT, so move it to the global header.
Also convert to bool return.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDon Dutile <ddutile@redhat.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Move pci_msi_set_enable() and pci_msix_clear_and_set_ctrl() to
drivers/pci/pci.h so they're available even when MSI isn't configured
into the kernel.

No functional change.

[bhelgaas: changelog, split into separate patch]
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NFam Zheng <famz@redhat.com>

The find_pci_host_bridge() function can be useful to other PCI code so
export it.  Change its name to pci_find_host_bridge().
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

An SR-IOV device can change its First VF Offset and VF Stride based on the
values of ARI Capable Hierarchy and NumVFs.  The number of buses required
for all VFs is determined by NumVFs, First VF Offset, and VF Stride (see
SR-IOV spec r1.1, sec 2.1.2).

Previously pci_iov_bus_range() computed how many buses would be required by
TotalVFs, but this was based on a single NumVFs value and may not have been
the maximum for all NumVFs configurations.

Iterate over all valid NumVFs and calculate the maximum number of bus
numbers that could ever be required for VFs of this device.

[bhelgaas: changelog, compute busnr of NumVFs, not TotalVFs, remove
kerenl-doc comment marker]
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Currently we don't store the individual VF BAR size.  We calculate it when
needed by dividing the PF's IOV resource size (which contains space for
*all* the VFs) by total_VFs or by reading the BAR in the SR-IOV capability
again.

Keep the individual VF BAR size in struct pci_sriov.barsz[], add
pci_iov_resource_size() to retrieve it, and use that instead of doing the
division or reading the SR-IOV capability BAR.

[bhelgaas: rename to "barsz[]", simplify barsz[] index computation, remove
SR-IOV capability BAR sizing]
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM
domain during system suspend) modified the ACPI PM domain's system
suspend callbacks to allow devices attached to it to be left in the
runtime-suspended state during system suspend so as to optimize
the suspend process.

This was based on the general mechanism introduced by commit
aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended
devices unnecessarily).

Extend that approach to PCI devices by modifying the PCI bus type's
->prepare callback to return 1 for devices that are runtime-suspended
when it is being executed and that are in a suitable power state and
need not be resumed going forward.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

Add pci_bus_clip_resource().  If a PCI-PCI bridge window overlaps an
upstream bridge window but is not completely contained by it, this clips
the downstream window so it fits inside the upstream one.

No functional change (this adds the function but no callers).

[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491Reported-by: NMarek Kordik <kordikmarek@gmail.com>
Fixes: 5b285415 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.16+

pci_iov_resource_bar() always sets its 'pci_bar_type' parameter to
'pci_bar_unknown'.  Drop the parameter and just use 'pci_bar_unknown'
directly in the callers.

No functional change intended.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Chris Wright <chrisw@sous-sol.org>
CC: Yu Zhao <yuzhao@google.com>

Previously we applied _HPX type 2 record Link Control register settings
only to bridges with a subordinate bus.  But it's better to apply them to
all devices with a link because if the subordinate bus has not been
allocated yet, we won't apply settings to the device.

Use pcie_cap_has_lnkctl() to determine whether the device has a Link
Control register instead of looking at dev->subordinate.

[bhelgaas: changelog]
Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration")
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Previously, pci_is_bridge() returned true only when a subordinate bus
existed.  Rename pci_is_bridge() to pci_has_subordinate() to better
indicate what we're checking.

No functional change.

[bhelgaas: changelog]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some PCI functions used to be marked __devinit.  When CONFIG_HOTPLUG was
not set, these functions were discarded after boot.  A few callers of these
__devinit functions were marked __ref to indicate that they could safely
call the __devinit functions even though the callers were not __devinit.

But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref
annotations is also gone, so remove them.  Relevant historical commits:

  54b956b9 Remove __dev* markings from init.h
  a8e4b9c1 PCI: add generic pci_hp_add_bridge()
  0ab2b57f PCI: fix section mismatch warning in pci_scan_child_bus
  451124a7 PCI: fix 4x section mismatch warnings
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This reverts commit 74bb1bcc ("PCI: handle SR-IOV Virtual Function
Migration"), removing this exported interface:

  pci_sriov_migration()

Since pci_sriov_migration() is unused, it is impossible to schedule
sriov_migration_task() or use any of the other migration infrastructure.

This is based on Stephen Hemminger's patch (see link below), but goes a bit
further.

Link: http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplumber.netSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Stephen Hemminger <stephen@networkplumber.org>

Using 'make namespacecheck' identify code which should be declared static.
Checked for users in other driver/archs as well.  Compile tested only.

This stops exporting the following interfaces to modules:

    pci_target_state()
    pci_load_saved_state()

[bhelgaas: retained pci_find_next_ext_capability() and pci_cfg_space_size()]
Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pcie_link_speed and pcix_bus_speed are arrays used by probe.c to correctly
convert lnksta register values into the pci_bus_speed enum. These static arrays
are useful outside probe for this purpose. This patch makes these defines into
conist arrays and exposes them with an extern header in drivers/pci/pci.h

-v2-
* move extern declarations to drivers/pci/pci.h

CC: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The dev_attrs field of struct class is going away soon, dev_groups
should be used instead.  This converts the PCI class code to use the
correct field.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

On x86 platforms, the kernel respects PCI resource assignments from
the BIOS and only reassigns resources for unassigned BARs at boot
time.  However, with the ACPI-based hotplug (acpiphp), it ignores the
BIOS' PCI resource assignments completely and reassigns all resources
by itself.  This causes differences in PCI resource allocation
between boot time and runtime hotplug to occur, which is generally
undesirable and sometimes actively breaks things.

Namely, if there are enough resources, reassigning all PCI resources
during runtime hotplug should work, but it may fail if the resources
are constrained.  This may happen, for instance, when some PCI
devices with huge MMIO BARs are involved in the runtime hotplug
operations, because the current PCI MMIO alignment algorithm may
waste huge chunks of MMIO address space in those cases.

On the Alexander's Sony VAIO VPCZ23A4R the BIOS allocates limited
MMIO resources for the dock station which contains a device
(graphics adapter) with a 256MB MMIO BAR.  An attempt to reassign
that during runtime hotplug causes the dock station MMIO window to be
exhausted and acpiphp fails to allocate resources for the majority
of devices on the dock station as a result.

To prevent that from happening, modify acpiphp to follow the boot
time resources allocation behavior so that the BIOS' resource
assignments are respected during runtime hotplug too.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=56531Reported-and-tested-by: NAlexander E. Patrakov <patrakov@gmail.com>
Tested-by: NIllya Klymov <xanf@xanf.me>
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.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>

We want to put pci_dev structs in the device tree as soon as possible so
for_each_pci_dev() iteration will not miss them, but driver attachment
needs to be delayed until after pci_assign_unassigned_resources() to make
sure all devices have resources assigned first.

This patch moves device registering from pci_bus_add_devices() to
pci_device_add(), which happens earlier, leaving driver attachment in
pci_bus_add_devices().

It also removes unattached child bus handling in pci_bus_add_devices().
That's not needed because child bus via pci_add_new_bus() is already
in parent bus children list.

[bhelgaas: changelog]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

pci_enable_ari() now supports enabling or disabling ARI forwarding.  So
rename pci_enable_ari() to pci_configure_ari() for easy understanding.

No functional change.

[bhelgaas: changelog]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Currently, the ACPI wakeup capability of PCI devices is set up
in two different places, partially in acpi_pci_bind() where
runtime wakeup is initialized and partially in
platform_pci_wakeup_init(), where system wakeup is initialized.
The cleanup is only done in acpi_pci_unbind() and it only covers
runtime wakeup.

Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type
to consolidate that code and do the setup and the cleanup each in one
place.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>

With the demise of CONFIG_HOTPLUG as an option, the pci_uevent
function located in hotplug.c will now always be used and doesn't need
special treatment in the Makefile.  Move pci_uevent into pci-driver.c
and remove hotplug.c
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove conditional code based on CONFIG_HOTPLUG being false.  It's
always on now in preparation of it going away as an option.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the same names (almost) as the spec for TotalVFs, InitialVFs, NumVFs.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some implementations of SRIOV provide a capability structure
value of TotalVFs that is greater than what the software can support.
Provide a method to reduce the capability structure reported value
to the value the driver can support.
This ensures sysfs reports the current capability of the system,
hardware and software.
Example for its use: igb & ixgbe -- report 8 & 64 as TotalVFs,
but drivers only support 7 & 63 maximum.
Signed-off-by: NDonald Dutile <ddutile@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Need type filled in device structure so it can be used for visible
attribute control in sysfs for pci_dev.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

In https://bugzilla.kernel.org/show_bug.cgi?id=48981
Peter reported that /proc/bus/pci/??/??.? does not work for 3.6.
This is because the device configuration space registers are
not accessible if the corresponding parent bridge is suspended or
the device is put into D3cold state.

This is the same as /sys/bus/pci/devices/0000:??:??.?/config access
issue.  So the function used to solve sysfs issue is used to solve
this issue.

This patch moves pci_config_pm_runtime_get()/_put() from pci/pci-sysfs.c
to pci/pci.c and makes them extern so they can be used by both the
sysfs and proc paths.

[bhelgaas: changelog, references, reporters]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48981
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=49031Reported-by: NForrest Loomis <cybercyst@gmail.com>
Reported-by: NPeter <lekensteyn@gmail.com>
Reported-by: NMicael Dias <kam1kaz3@gmail.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+