Save the position of the error reporting capability so it doesn't need to
be rediscovered during error handling.
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Lukas Wunner <lukas@wunner.de>

Allow root port buses to choose to skip source id matching when finding the
faulting device.  Certain root port devices may return an incorrect source
ID and recommend to scan child device registers for AER notifications.
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PTM Control register (PCIe r3.1, sec 7.32.3) contains an Effective
Granularity field:

  This provides information relating to the expected accuracy of the PTM
  clock, but does not otherwise affect the PTM mechanism.

Set the Effective Granularity based on the PTM Root and any intervening PTM
Time Sources.

This does not set Effective Granularity for Root Complex Integrated
Endpoints because I don't know how to figure out clock granularity for
them.  The spec says:

  ... system software must set [Effective Granularity] to the value
  reported in the Local Clock Granularity field by the associated PTM
  Time Source.

but I don't know how to identify the associated PTM Time Source.  Normally
it's the upstream bridge, but an integrated endpoint has no upstream
bridge.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add an pci_enable_ptm() interface so drivers can enable PTM.

The PCI core enables PTM on PTM Roots and switches automatically, but we
don't enable PTM on endpoints unless a driver requests it.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add Precision Time Measurement (PTM) support (see PCIe r3.1, sec 6.22).

Enable PTM on PTM Root devices and switch ports.  This does not enable PTM
on endpoints.

There currently are no PTM-capable devices on the market, but it is
expected to be supported by the Intel Apollo Lake platform.

[bhelgaas: complete rework]
Signed-off-by: NJonathan Yong <jonathan.yong@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

A user may hot add a switch requiring more than one bus to enumerate.  This
previously required a system reboot if BIOS did not sufficiently pad the
bus resource, which they frequently don't do.

Add a kernel parameter so a user can specify the minimum number of bus
numbers to reserve for a hotplug bridge's subordinate buses so rebooting
won't be necessary.

The default is 1, which is equivalent to previous behavior.
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Set the affinity_mask in the PCI device before allocating vectors so that
the affinity can be propagated through the MSI descriptor structures to the
core IRQ code.  To facilitate this, new __pci_enable_msi_range() and
__pci_enable_msix_range() helpers are factored out of their not prefixed
variants which assigning the new IRQ affinity mask in the PCI device so
that the low-level interrupt code can perform the interrupt affinity
assignment and do node-local allocations.

A new PCI_IRQ_NOAFFINITY flag is added to pci_alloc_irq_vectors() so that
this function can also be used by drivers that don't wish to use the
automatic affinity assignment.

[bhelgaas: omit "else" after "return" consistently]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlexander Gordeev <agordeev@redhat.com>

Add a function to allocate and free a range of interrupt vectors, using
MSI-X, MSI or legacy vectors (in that order) based on the capabilities of
the underlying device and PCIe complex.

Additionally a new helper is provided to get the Linux IRQ number for given
device-relative vector so that the drivers don't need to allocate their own
arrays to keep track of the vectors for the multi vector MSI-X case.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlexander Gordeev <agordeev@redhat.com>

All PCI resources (bridge windows and BARs) should be inserted in the
iomem_resource and ioport_resource trees so we know what space is occupied
and what is available for other devices.  There's nothing arch-specific
about this, but it is currently done by arch-specific code.

Add a generic pci_bus_claim_resources() interface so we can migrate away
from the arch-specific code.

[bhelgaas: changelog]
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Yinghai Lu <yinghai@kernel.org>

Add helpers to request and release a device's memory or I/O regions.

With these helpers in place, one does not need to select a device's memory
or I/O regions with pci_select_bars() prior to requesting or releasing
them.
Suggested-by: NChristoph Hellwig <hch@infradead.org>
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>

Currently, PowerPC PowerNV platform utilizes ppc_md.pcibios_fixup(),
which is called for once after PCI probing and resource assignment
are completed, to allocate platform required resources for PCI devices:
PE#, IO and MMIO mapping, DMA address translation (TCE) table etc.
Obviously, it's not hotplug friendly.

This adds weak function pcibios_setup_bridge(), which is called by
pci_setup_bridge(). PowerPC PowerNV platform will reuse the function
to assign above platform required resources to newly plugged PCI devices
during PCI hotplug in subsequent patches.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The dev.pme_support field, pci_pm_init(), pci_pme_capable(), and
pci_raw_set_power_state() depend on the fact that the pci_power_t values
(PCI_D0, PCI_D1, etc.) match the definition of the Capabilities PME_Support
and the Control/Status PowerState fields in the Power Management capability
(see PCI Bus Power Management spec r1.2, sec 3.2.3).

Add a note to this effect at the pci_power_t typedef.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Replace the pci_resource_to_user() declarations in each arch that defines
HAVE_ARCH_PCI_RESOURCE_TO_USER with a single one in linux/pci.h.

Change the MIPS static inline implementation to a non-inline version so the
static inline doesn't conflict with the new non-static linux/pci.h
declaration.

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

Currently the Linux PCI core does not touch power state of PCI bridges and
PCIe ports when system suspend is entered.  Leaving them in D0 consumes
power unnecessarily and may prevent the CPU from entering deeper C-states.

With recent PCIe hardware we can power down the ports to save power given
that we take into account few restrictions:

  - The PCIe port hardware is recent enough, starting from 2015.

  - Devices connected to PCIe ports are effectively in D3cold once the port
    is transitioned to D3 (the config space is not accessible anymore and
    the link may be powered down).

  - Devices behind the PCIe port need to be allowed to transition to D3cold
    and back.  There is a way both drivers and userspace can forbid this.

  - If the device behind the PCIe port is capable of waking the system it
    needs to be able to do so from D3cold.

This patch adds a new flag to struct pci_device called 'bridge_d3'.  This
flag is set and cleared by the PCI core whenever there is a change in power
management state of any of the devices behind the PCIe port.  When system
later on is suspended we only need to check this flag and if it is true
transition the port to D3 otherwise we leave it in D0.

Also provide override mechanism via command line parameter
"pcie_port_pm=[off|force]" that can be used to disable or enable the
feature regardless of the BIOS manufacturing date.
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When casting variables of type pci_power_t, a static analysis tool complains:

  include/linux/pci.h:119:37: warning: cast from restricted pci_power_t

Enforce type casting to make the static analyzer happy.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Extend pci_bus_find_domain_nr() so it can find the domain from either:

  - ACPI, via the new acpi_pci_bus_find_domain_nr() interface, or
  - DT, via of_pci_bus_find_domain_nr()

Note that this is only used for CONFIG_PCI_DOMAINS_GENERIC=y, so it does
not affect x86 or ia64.

[bhelgaas: changelog]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Instead of assigning bus->domain_nr inside pci_bus_assign_domain_nr(),
return the domain and let the caller do the assignment.  Rename
pci_bus_assign_domain_nr() to pci_bus_find_domain_nr() to reflect this.

No functional change intended.

[bhelgaas: changelog]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

On ACPI systems that support memory-mapped config space access, i.e., ECAM,
the PCI Firmware Specification says the OS can learn where the ECAM space
is from either:

  - the static MCFG table (for non-hotpluggable bridges), or
  - the _CBA method (for hotpluggable bridges)

The current MCFG table handling code cannot be easily generalized owing to
x86-specific quirks, which makes it hard to reuse on other architectures.

Implement generic MCFG handling from scratch, including:

  - Simple MCFG table parsing (via pci_mmcfg_late_init() as in current x86)
  - MCFG region lookup for a (domain, bus_start, bus_end) tuple

[bhelgaas: changelog]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NJayachandran C <jchandra@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Add pci_unmap_iospace() to undo what pci_remap_iospace() did.

This is needed to support hotplug removal of host bridges that use
pci_remap_iospace().

[bhelgaas: changelog]
Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Several host bridge drivers iterate through the list of bridge windows to
request resources.  Several others don't request the window resources at
all.

Add a devm_request_pci_bus_resources() interface to make it easier for
drivers to request all the window resources.  Export to GPL modules (from
Arnd Bergmann <arnd@arndb.de>).
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

No functional changes in this patch.

PCI I/O space mapping code does not depend on OF; therefore it can be moved
to PCI core code.  This way we will be able to use it, e.g., in ACPI PCI
code.
Suggested-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Liviu Dudau <Liviu.Dudau@arm.com>

The original thought was that if a device implemented ACS, then surely
we want to use that... well, it turns out that devices can make an ACS
capability so broken that we still need to fall back to quirks.

Reverse the order of ACS enabling to give quirks first shot at it.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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>

Solve IOMMU support issues with PCIe non-transparent bridges that use
Requester ID look-up tables (RID-LUT), e.g., the PEX8733.

The NTB connects devices in two independent PCI domains.  Devices separated
by the NTB are not able to discover each other.  A PCI packet being
forwared from one domain to another has to have its RID modified so it
appears on correct bus and completions are forwarded back to the original
domain through the NTB.  The RID is translated using a preprogrammed table
(LUT) and the PCI packet propagates upstream away from the NTB.  If the
destination system has IOMMU enabled, the packet will be discarded because
the new RID is unknown to the IOMMU.  Adding a DMA alias for the new RID
allows IOMMU to properly recognize the packet.

Each device behind the NTB has a unique RID assigned in the RID-LUT.  The
current DMA alias implementation supports only a single alias, so it's not
possible to support mutiple devices behind the NTB when IOMMU is enabled.

Enable all possible aliases on a given bus (256) that are stored in a
bitset.  Alias devfn is directly translated to a bit number.  The bitset is
not allocated for devices that have no need for DMA aliases.

More details can be found in the following article:
http://www.plxtech.com/files/pdf/technical/expresslane/RTC_Enabling%20MulitHostSystemDesigns.pdfSigned-off-by: NJacek Lawrynowicz <jacek.lawrynowicz@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Acked-by: NJoerg Roedel <jroedel@suse.de>

Add a pci_add_dma_alias() interface to encapsulate the details of adding an
alias.  No functional change intended.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>

This adds weak function pcibios_bus_add_device() for arch dependent
code could do proper setup. For example, powerpc could setup EEH
related resources for SRIOV VFs.
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Reviewed-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

During EEH recovery, hotplug is applied to the devices which don't
have drivers or their drivers don't support EEH. However, the hotplug,
which was implemented based on PCI bus, can't be applied to VF directly.
Instead, we unplug and plug individual PCI devices (VFs).

This renames virtn_{add,remove}() and exports them so they can be used
in PCI hotplug during EEH recovery.
Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
Reviewed-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Add pci_ops.{add,remove}_bus() callbacks, which will be called on every
newly created bus and when a bus is being removed, respectively.  This can
be used by drivers to implement driver-specific initialization and teardown
of the bus, in addition to the architecture-specifics implemented by the
pcibios_add_bus() and the pcibios_remove_bus() functions.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Christoph added a generic include/linux/pci-dma-compat.h, so now there's
one place with most of the PCI DMA interfaces.  Move more PCI DMA-related
things there:

  - The PCI_DMA_* direction constants from linux/pci.h
  - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary()
    CONFIG_PCI implementations from drivers/pci/pci.c
  - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary()
    !CONFIG_PCI stubs from linux/pci.h
  - The pci_set_dma_mask() and pci_set_consistent_dma_mask()
    !CONFIG_PCI stubs from linux/pci.h
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

For a long time all architectures implement the pci_dma_* functions using
the generic DMA API, and they all use the same header to do so.

Move this header, pci-dma-compat.h, to include/linux and include it from
the generic pci.h instead of having each arch duplicate this include.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Tested-by: NAndi Kleen <ak@linux.intel.com>
CC: stable@vger.kernel.org

The 'end' tag is actually 0x0f; it's the representation as a small resource
data type tag that's 0x78 (i.e., shifted by 3).  Correct PCI_VPD_STIN_END
and PCI_VPD_SRDT_END accordingly.

Also, add helper functions to extract the resource data type tags for both
large and small resource data types.

[bhelgaas: changelog]
Tested-by: NShane Seymour <shane.seymour@hpe.com>
Tested-by: NBabu Moger <babu.moger@oracle.com>
Signed-off-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>

Revert 811a4e6f ("PCI: Add helpers to manage pci_dev->irq and
pci_dev->irq_managed").

This is part of reverting 991de2e5 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>

Add an fwnode_handle to the x86 struct pci_sysdata, which will be used to
locate an IRQ domain associated with a root PCI bus.

[bhelgaas: changelog]
Signed-off-by: NJake Oshins <jakeo@microsoft.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The PCI flag management constants and functions were previously declared in
include/asm-generic/pci-bridge.h.  But they are not specific to bridges,
and arches did not include pci-bridge.h consistently.

Move the following interfaces and related constants to include/linux/pci.h
and remove pci-bridge.h:

  pci_set_flags()
  pci_add_flags()
  pci_clear_flags()
  pci_has_flag()

This fixes these warnings when building for some arches:

  drivers/pci/host/pcie-designware.c:562:20: error: 'PCI_PROBE_ONLY' undeclared (first use in this function)
  drivers/pci/host/pcie-designware.c:562:7: error: implicit declaration of function 'pci_has_flag' [-Werror=implicit-function-declaration]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch introduces pci_msi_register_fwnode_provider() for irqchip
to register a callback, to provide a way to determine appropriate MSI
domain for a pci device.

It also introduces pci_host_bridge_acpi_msi_domain(), which returns
the MSI domain of the specified PCI host bridge with DOMAIN_BUS_PCI_MSI
bus token. Then, it is assigned to pci device.
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.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>

1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't
support MSI") moved dev->msi_cap and dev->msix_cap initialization from the
pci_init_capabilities() path (used on all architectures) to the
pci_setup_device() path (not used on Open Firmware architectures).

This broke MSI or MSI-X on Open Firmware machines.  4d9aac39
("powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case")
fixed it for PowerPC but not for SPARC.

Set up MSI and MSI-X (initialize msi_cap and msix_cap and disable MSI and
MSI-X) in pci_init_capabilities() so all architectures do it the same way.

This reverts 4d9aac39 since this patch fixes the problem generically
for both PowerPC and SPARC.

[bhelgaas: changelog, make pci_msi_setup_pci_dev() static]
Fixes: 1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
Unexpected Completion errors in some systems, which may cause device access
timeouts.

Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
for the Attribute as were supplied in the header of the corresponding
Request, except as explicitly allowed when IDO is used."

Instead of copying the Attributes from the Request to the Completion, the
T5 always generates Completions with zero Attributes.  The receiver of a
Completion whose Attributes don't match the Request may accept it (which
itself seems non-compliant based on sec 2.3.2), or it may handle it as a
Malformed TLP or an Unexpected Completion, which will probably lead to a
device access timeout.

Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
Port so it always generate Requests with zero Attributes.

This does affect all other devices which are downstream of that Root Port,
but these are performance optimizations that should not make a functional
difference.

Note that Configuration Space accesses are never supposed to have TLP
Attributes, so we're safe waiting till after any Configuration Space
accesses to do the Root Port "fixup".

Based on original work by Casey Leedom <leedom@chelsio.com>

[bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
to use pci_upstream_bridge() and check for Root Port device type, edit
diagnostics to clarify intent and devices affected]
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

In f309d444 ("platform_device: better support builtin boilerplate
avoidance"), we introduced the builtin_driver() macro.

Here we use that support and extend it to PCI driver registration, so where
a driver is clearly non-modular and builtin-only, we can register it in a
similar fashion.  Existing code that is clearly non-modular can be updated
with the simple mapping of

  module_pci_driver(...)  ---> builtin_pci_driver(...)

We've essentially cloned the former to make the latter, and taken out the
remove/module_exit parts since those never get used in a non-modular build
of the code.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>