* pci/don-sriov:
  PCI: SRIOV control and status via sysfs (documentation)

* pci/misc:
  PCI/AER: Report success only when every device has AER-aware driver

Conflicts:
	drivers/pci/pcie/aer/aerdrv_core.c

Add documentation of new sysfs files and new pci_driver SRIOV
configuration interface.

[bhelgaas: changelog]
Signed-off: Donald Dutile <ddutile@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

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: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Linas Vepstas <linasvepstas@gmail.com>
Reviewed-by: Myron Stowe <myron.stowe@redhat.com>

* for-linus:
  PCI/portdrv: Don't create hotplug slots unless port supports hotplug
  PCI/PM: Fix proc config reg access for D3cold and bridge suspending
  PCI/PM: Resume device before shutdown
  PCI/PM: Fix deadlock when unbinding device if parent in D3cold

* pci/misc:
  PCI/ACPI: Notify PCI devices when their power resource is turned on
  PCI: Add GPL license for drivers/pci/ioapic module
  PCI: Fix bit definitions of PCI_EXP_LNKCAP2 register

* pci/don-sriov:
  PCI: Remove useless "!dev" tests
  PCI: Use spec names for SR-IOV capability fields
  PCI: Provide method to reduce the number of total VFs supported
  PCI: SRIOV control and status via sysfs
  PCI: Use is_visible() with boot_vga attribute for pci_dev
  PCI: Add pci_device_type to pdev's device struct

This patch reduces power consumption by allowing idle devices to go to a
low power state after another device on the same power resource has been
awakened.

A power resource may be shared by multiple devices.  When all devices
sharing a power resource are put into D3_COLD state, the power resource
will be turned off.  When one of the devices is awakened, the power
resource will be turned on and all devices sharing it will be powered on to
D0uninitialized state.  These devices should be resumed, so that they have
the opportunity to go to low power state later.

[bhelgaas: changelog]
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>

Config PCI_IOAPIC turned into a tristate in commit b95a7bd7, but no
module license is specified.  This adds the missing module license.
Signed-off-by: Andrew Cooks <acooks@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

No need to check "!dev" when the caller should always supply a valid
pointer.  If the caller *doesn't* supply a valid pointer, it probably
won't check for a failure return either.  This way we'll oops and get a
backtrace.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Use the same names (almost) as the spec for TotalVFs, InitialVFs, NumVFs.
Signed-off-by: Bjorn 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: Donald Dutile <ddutile@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Provide files under sysfs to determine the maximum number of VFs
an SR-IOV-capable PCIe device supports, and methods to enable and
disable the VFs on a per-device basis.

Currently, VF enablement by SR-IOV-capable PCIe devices is done
via driver-specific module parameters.  If not setup in modprobe files,
it requires admin to unload & reload PF drivers with number of desired
VFs to enable.  Additionally, the enablement is system wide: all
devices controlled by the same driver have the same number of VFs
enabled.  Although the latter is probably desired, there are PCI
configurations setup by system BIOS that may not enable that to occur.

Two files are created for the PF of PCIe devices with SR-IOV support:

    sriov_totalvfs	Contains the maximum number of VFs the device
			could support as reported by the TotalVFs register
			in the SR-IOV extended capability.

    sriov_numvfs	Contains the number of VFs currently enabled on
			this device as reported by the NumVFs register in
			the SR-IOV extended capability.

			Writing zero to this file disables all VFs.

			Writing a positive number to this file enables that
			number of VFs.

These files are readable for all SR-IOV PF devices.  Writes to the
sriov_numvfs file are effective only if a driver that supports the
sriov_configure() method is attached.
Signed-off-by: Donald Dutile <ddutile@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Should make pci_create_sysfs_dev_files() simpler.  Also fix possible
memleak in remove path.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn 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: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

According to the PCIe 3.0 spec, PCI_EXP_LNKCAP2_SLS_2_5GB is
1st bit of PCI_EXP_LNKCAP2 register, not 0th bit. So, the bit
definition of supported link speed vector should be fixed.

[bhelgaas: change "Current" to "Supported"]
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

* pci/mike-x86-tra:
  x86/PCI: Allow x86 platforms to use translation offsets

* pci/taku-prt-cleanup:
  PCI/ACPI: Request _OSC control before scanning PCI root bus
  PCI: Don't pass pci_dev to pci_ext_cfg_avail()
  PCI/ACPI: Add _PRT interrupt routing info before enumerating devices
  ACPI: Pass segment/bus to _PRT add/del so they don't depend on pci_bus

* pci/yinghai-for-pci-root-bus-hotplug:
  PCI/ACPI: Remove acpi_root_driver in reverse order
  PCI/ACPI: Delete host bridge _PRT during hot remove path
  PCI/ACPI: Make acpi_pci_root_remove() stop/remove pci root bus
  PCI: Add pci_stop_and_remove_root_bus()
  PCI/ACPI: Assign unassigned resource for hot-added root bus
  PCI: Move out pci_enable_bridges out of assign_unsigned_bus_res
  PCI: Move pci_rescan_bus() back to probe.c
  PCI: Separate out pci_assign_unassigned_bus_resources()

* pci/misc:
  PCI/PM: Add comments for PME poll support for PCIe
  PCI: Add PLX PCI 9050 workaround for some Meilhaus DAQ cards
  PCI: Add workaround for PLX PCI 9050 BAR alignment erratum
  PCI: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
  x86/PCI: Ignore _SEG on HP xw9300
  PCI: Don't touch card regs after runtime suspend D3

The memory range descriptors in the _CRS control method contain an address
translation offset for host bridges.  This value is used to translate
addresses across the bridge.  The support to use _TRA values is present for
other architectures but not for X86 platforms.

For existing X86 platforms the _TRA value is zero.  Non-zero _TRA values
are expected on future X86 platforms.  This change will register that value
with the resource.
Signed-off-by: Mike Yoknis <mike.yoknis@hp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

There are comments on why PME poll support is necessary for PCI
devices, but not for PCIe devices.  That may lead to misunderstanding
that PME poll is only necessary for PCI devices.  So add comments
related to PCIe PME poll to make it more clear.

The content of comments comes from the changelog of commit:

379021d5Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The Meilhaus ME-2000i and ME-2600i data acquisition cards supported by
the Comedi "me_daq" driver use the PLX PCI 9050 PCI Target bridge chip
affected by the bug that prevents the chip's local configuration
registers being read from BAR0 or BAR1 base addresses that are an odd
multiple of 128 bytes.  Use the PLX PCI 9050 quirk handler for these
devices to re-allocate affected regions to a 256-byte boundary.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The PLX PCI 9050 PCI Target bridge controller has a bug that prevents
its local configuration registers being read through BAR0 (memory) or
BAR1 (i/o) if the base address lies on an odd 128-byte boundary, i.e. if
bit 7 of the base address is non-zero.  This bug is described in the PCI
9050 errata list, version 1.4, May 2005.  It was fixed in the
pin-compatible PCI 9052, which can be distinguished from the PCI 9050 by
checking the revision in the PCI header, which is hard-coded for these
chips.

Workaround the problem by re-allocating the affected regions to a
256-byte boundary.  Note that BAR0 and/or BAR1 may have been disabled
(size 0) during initialization of the PCI chip when its configuration is
read from a serial EEPROM.

Currently, the fix-up has only been used for devices with the default
vendor and device ID of the PLX PCI 9050.  The PCI 9052 shares the same
default device ID as the PCI 9050 but they have different PCI revision
codes.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

dev_<level> calls take less code than dev_printk(KERN_<LEVEL>
and reducing object size is good.
Coalesce formats for easier grep.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The xw9300 BIOS supplies _SEG methods that are incorrect, which results
in some LSI SCSI devices not being discovered.  This adds a quirk to
ignore _SEG on this machine and default to zero.

The xw9300 has three host bridges:

    ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f])
    ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 40-7f])
    ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 80-ff])

When the BIOS "ACPI Bus Segmentation" option is enabled (as it is by
default), the _SEG methods of the PCI1 and PCI2 bridges return 1 and 2,
respectively.  However, the BIOS implementation appears to be incomplete,
and we can't enumerate devices in those domains.

But if we assume PCI1 and PCI2 really lead to buses in domain 0,
everything works fine.  Windows XP and Vista also seem to ignore
these _SEG methods.

Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543308
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15362Reported-and-Tested-by: Sean M. Pappalardo <pegasus@renegadetech.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

If the driver takes care of state saving, don't touch any registers on it.

Optimus (dual-gpu) laptops seem to have their own form of D3cold, but
unfortunately enter it on normal D3 transitions via the ACPI callback.

So when we use runtime PM to transition to D3, the card disappears off
the PCI bus, however we then try to access registers on it in the
runtime suspend finish, which really doesn't work.

This patch checks whether the pci state is saved and doesn't attempt to hit
any registers after that point if it is.

(Looks okay to Rafael)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

This patch moves up the code block to request _OSC control in order to
separate ACPI work and PCI work in acpi_pci_root_add().
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

pci_ext_cfg_avail() doesn't use the "struct pci_dev *" passed to
it, and there's no requirement that a host bridge even be represented
by a pci_dev.  This drops the pci_ext_cfg_avail() parameter.

[bhelgaas: changelog]
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Commit 2dcfaf85 mistakenly dropped the "flags & PCI_EXP_FLAGS_SLOT" test,
so now we create hotplug slots even for PCIe port devices that don't
support hotplug.  This patch fixes this problem.

[bhelgaas: changelog]
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Reviewed-by: Jiang Liu <jiang.liu@huawei.com>

* pci/huang-d3cold-fixes:
  PCI/PM: Fix proc config reg access for D3cold and bridge suspending
  PCI/PM: Resume device before shutdown
  PCI/PM: Fix deadlock when unbinding device if parent in D3cold

We used to add the _PRT after enumerating devices behind a new host
bridge.  This moves the _PRT addition *before* the enumeration, since
it no longer depends on the struct pci_bus existing.  This is one
step towards consolidating the .add/.start methods.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Taku Izumi <izumim.taku@jp.fujitsu.com>

This effectively reverts 859a3f86 ("ACPI: simplify
acpi_pci_irq_add_prt() API") and d9efae36 ("ACPI: simplify
acpi_pci_irq_del_prt() API").

The reason is to disentangle these routines from the struct pci_bus.
We want to be able to add the _PRT before the struct pci_bus
exists, and delete the _PRT after we've removed the pci_bus.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.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: Forrest Loomis <cybercyst@gmail.com>
Reported-by: Peter <lekensteyn@gmail.com>
Reported-by: Micael Dias <kam1kaz3@gmail.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org		# v3.6+

Call the sub-driver .remove() methods in the reverse order of the
.add() methods for symmetry.

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

Corresponding to add path.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

It will call pci_stop_and_remove_bus() to stop/remove pci root bus.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: linux-acpi@vger.kernel.org

It supports both PCI root bus and PCI bus under PCI bridge.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

After we get hot-added IOAPIC registered.
pci_enable_bridges() will try to enable IOAPIC IRQ for PCI bridges.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

So could use assign_unassigned_bus_res pci root bus add
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>