* pci/msi:
  PCI/MSI: Enable PCI_MSI_IRQ_DOMAIN support for ARC

* pci/misc:
  PCI: Drop CONFIG_KEXEC_CORE ifdeffery

* pci/hotplug:
  x86/PCI: VMD: Request userspace control of PCIe hotplug indicators
  PCI: pciehp: Allow exclusive userspace control of indicators
  PCI: pciehp: Remove useless pciehp_get_latch_status() calls
  PCI: pciehp: Clean up dmesg "Slot(%s)" messages
  PCI: pciehp: Remove unnecessary guard
  PCI: pciehp: Don't re-read Slot Status when handling surprise event
  PCI: pciehp: Don't re-read Slot Status when queuing hotplug event
  PCI: pciehp: Process all hotplug events before looking for new ones
  PCI: pciehp: Return IRQ_NONE when we can't read interrupt status
  PCI: pciehp: Rename pcie_isr() locals for clarity
  PCI: pciehp: Clear attention LED on device add

* pci/enumeration:
  PCI: tegra: Fix pci_remap_iospace() failure path
  PCI: generic: Fix pci_remap_iospace() failure path
  PCI: rcar: Fix pci_remap_iospace() failure path
  PCI: versatile: Fix pci_remap_iospace() failure path
  PCI: designware: Fix pci_remap_iospace() failure path
  PCI: aardvark: Fix pci_remap_iospace() failure path

* pci/aer:
  PCI/AER: Fix aer_probe() kernel-doc comment
  PCI/AER: Cache capability position
  PCI/AER: Avoid memory allocation in interrupt handling path
  ACPI / APEI: Send correct severity to calculate AER severity
  PCI/AER: Remove duplicate AER severity translation
  PCI/AER: Remove aerdriver.forceload kernel parameter
  PCI/AER: Remove aerdriver.nosourceid kernel parameter
  x86/PCI: VMD: Add quirk for AER to ignore source ID
  PCI/AER: Add bus flag to skip source ID matching

Conflicts:
	drivers/pci/probe.c

0516c8bc ("PCI: PCIe portdrv: Simplily probe callback of service
drivers") removed the "id" argument of aer_probe() but neglected to remove
the kernel-doc comment.  Update the comment.

[bhelgaas: changelog]
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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>

When handling AER events, we previously allocated a struct aer_err_info,
processed the error, and freed the struct.  But aer_isr_one_error() is
serialized by rpc_mutex, so we never need more than one copy of the struct,
and the struct is only about 70 bytes, so we're not saving much by
allocating it dynamically.

Embed a struct aer_err_info directly in struct aer_rpc, which is allocated
at probe-time by aer_probe().

[bhelgaas: changelog]
Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Add set_dev_domain_options() to set PCI domain-specific options as devices
are added.  The first usage is to request exclusive userspace control of
PCIe hotplug indicators in VMD domains.

Devices in a VMD domain use PCIe hotplug Attention and Power Indicators in
a non-standard way; tell pciehp to ignore the indicators so userspace can
control them via the sysfs "attention" file.

To determine whether a bus is within a VMD domain, add a bool to the
pci_sysdata structure that the VMD driver sets during initialization.

[bhelgaas: changelog]
Requested-by: NKapil Karkra <kapil.karkra@intel.com>
Tested-by: NArtur Paszkiewicz <artur.paszkiewicz@intel.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

PCIe hotplug supports optional Attention and Power Indicators, which are
used internally by pciehp.  Users can't control the Power Indicator, but
they can control the Attention Indicator by writing to a sysfs "attention"
file.

The Slot Control register has two bits for each indicator, and the PCIe
spec defines the encodings for each as (Reserved/On/Blinking/Off).  For
sysfs "attention" writes, pciehp_set_attention_status() maps into these
encodings, so the only useful write values are 0 (Off), 1 (On), and 2
(Blinking).

However, some platforms use all four bits for platform-specific indicators,
and they need to allow direct user control of them while preventing pciehp
from using them at all.

Add a "hotplug_user_indicators" flag to the pci_dev structure.  When set,
pciehp does not use either the Attention Indicator or the Power Indicator,
and the low four bits (values 0x0 - 0xf) of sysfs "attention" write values
are written directly to the Attention Indicator Control and Power Indicator
Control fields.

[bhelgaas: changelog, rename flag and accessors to s/attention/indicator/]
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Currently the AER severity is calculated by calling cper_severity_to_aer(),
but the parameter sent is actually the GHES severity.  This causes the AER
severity to be incorrect.

Fix the parameter to be the CPER severity instead of the GHES severity.
Signed-off-by: NTyler Baicar <tbaicar@codeaurora.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NBorislav Petkov <bp@suse.de>

Currently the AER severity is being translated twice in the code flow for
PCIe errors.  It is first translated in ghes_do_proc() before calling into
the AER driver.  Then it is translated again when the AER driver calls
cper_print_aer().  This causes the severity that is used in
cper_print_aer() to be incorrect.

Remove the second translation that is in cper_print_aer() since this
function is already receiving the correct AER severity.
Signed-off-by: NTyler Baicar <tbaicar@codeaurora.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NBorislav Petkov <bp@suse.de>

Per the PCI Firmware spec, r3.0, sec 4.5.1, on ACPI systems, the OS must
not use AER unless _OSC is present and _OSC grants AER control to the OS.
The aerdriver.forceload kernel parameter was a way to enable Linux AER
support on ACPI systems that lack _OSC or fail to grant control the the OS.

Enabling Linux AER support when the firmware doesn't want us to is a recipe
for problems, e.g., the firmware might be handling AER itself.

Remove the aerdriver.forceload kernel parameter and related supporting
code.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The aerdriver.nosourceid kernel parameter was intended for working around
broken chipsets don't supply the source ID for AER events.  We recently
added PCI_BUS_FLAGS_NO_AERSID, which can be set by quirks for the same
purpose.

Remove the aerdriver.nosourceid kernel parameter.  For anything other than
debugging, asking users to find and use kernel parameters is a poor user
experience.  Instead, we should add PCI_BUS_FLAGS_NO_AERSID quirks for any
hardware that needs it.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Long ago, we updated a "switch_save" field based on the latch status.  But
switch_save was unused, and ed6cbcf2 ("[PATCH] pciehp: miscellaneous
cleanups") removed it.

We no longer use the latch status, so remove calls to
pciehp_get_latch_status().  No functional change intended.
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Print slot name consistently as "Slot(%s)".  I don't know whether that's
ideal, but we can at least do it the same way all the time.  No functional
change intended.
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

In pcie_isr(), we return early if no status bits other than
PCI_EXP_SLTSTA_CC are set.  This was introduced by dbd79aed ("pciehp:
fix NULL dereference in interrupt handler"), but it is no longer necessary
because all the subsequent pcie_isr() code is already predicated on a
status bit being set.

Remove the unnecessary test for ~PCI_EXP_SLTSTA_CC.  No functional change
intended.
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Previously we read Slot Status when handling a surprise event.  But Slot
Status might have changed since we identified the event, and the event_type
already tells us whether to enable or disable the slot, so there's no need
to read it again.

Remove handle_surprise_event() and queue the power work directly.

[bhelgaas: changelog]
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMayurkumar Patel <mayurkumar.patel@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NRajat Jain <rajatxjain@gmail.com>

Previously we read Slot Status to learn about hotplug events, then cleared
the events, then re-read Slot Status to find out what happened.  But Slot
Status might have changed before the second read.

Capture the Slot Status once before clearing the events.  Also capture the
Link Status if we had a link status change.

[bhelgaas: changelog, split to separate patch]
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMayurkumar Patel <mayurkumar.patel@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Previously we accumulated hotplug events, then processed them, essentially
like this:

  events = 0
  do {
    status = read(Slot Status)
    status &= EVENT_MASK              # only look at events
    events |= status                  # accumulate events
    write(Slot Status, events)        # clear events
  } while (status)
  process events

The problem is that as soon as we clear events in Slot Status, the hardware
may send notifications for new events, and we lose information about the
first events.  For example, we might see two Presence Detect Changed
events, but lose the fact that the slot was temporarily empty:

  read  PCI_EXP_SLTSTA_PDC set, PCI_EXP_SLTSTA_PDS clear  # slot empty
  write PCI_EXP_SLTSTA_PDC                                # clear PDC event
  read  PCI_EXP_SLTSTA_PDC set, PCI_EXP_SLTSTA_PDS set    # slot occupied

The current code does not process a removal; it only processes the
insertion, which fails because we didn't remove the original device.

To avoid this problem, read Slot Status once and process all the events
before reading it again, like this:

  do {
    read events
    clear events
    process events
  } while (events)

[bhelgaas: changelog, add external loop around pciehp_isr()]
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMayurkumar Patel <mayurkumar.patel@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

After 1469d17d ("PCI: pciehp: Handle invalid data when reading from
non-existent devices"), we returned IRQ_HANDLED when we failed to read
interrupt status from the bridge.  I think it's better to return IRQ_NONE,
as we do in other cases where there's no interrupt pending.  This will
facilitate refactoring the loop in pcie_isr(): we'll be able to call the
ISR in a loop as long as it returns IRQ_HANDLED.

Return IRQ_NONE if we couldn't read interrupt status.
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Rename "detected" and "intr_loc" to "status" and "events" for clarity.
"status" is the value we read from the Slot Status register; "events" is
the set of hot-plug events we need to process.  No functional change
intended.
Tested-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

VMD root ports change all source ids to the VMD device ID.  To find the
sender of the AER notification, we need to scan all child devices for the
AER sender, rather than relying on the source ID from the message.
Signed-off-by: NJon Derrick <jonathan.derrick@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

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>

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI tegra host bridge driver adds the PCI IO resource retrieved from
firmware to the host bridge resource windows even if the
pci_remap_iospace() call fails; this is an actual bug in that the PCI host
bridge would consider the PCI IO resource valid (and possibly assign it to
downstream devices) even if the kernel was not able to map the PCI host
bridge memory address driving IO cycle to the CPU virtual address space (ie
pci_remap_iospace() failures).

Add the PCI host bridge driver pci_remap_iospace() failure path and do not
add the corresponding PCI host bridge PCI IO resources retrieved through
firmware when the pci_remap_iospace() function call fails, fixing the
issue.

Fixes: e6e9f471 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one")
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Thierry Reding <treding@nvidia.com>

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI common host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: 4e64dbe2 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers")
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NWill Deacon <will.deacon@arm.com>

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI rcar host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: 5d2917d4 ("PCI: rcar: Convert to DT resource parsing API")
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Phil Edworthy <phil.edworthy@renesas.com>
CC: Simon Horman <horms+renesas@verge.net.au>

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI versatile host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: b7e78170 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver")
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Rob Herring <robh@kernel.org>

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI designware host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: cbce7900 ("PCI: designware: Make driver arch-agnostic")
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Pratyush Anand <pratyush.anand@gmail.com>

On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridge's memory address space driving PCI IO
cycles to it.

PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.

This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.

The PCI aardvark host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).

Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.

Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Add ARC as an arch that supports PCI_MSI_IRQ_DOMAIN and add generation of
msi.h in the ARC arch.
Signed-off-by: NJoao Pinto <jpinto@synopsys.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>

* pci/ptm:
  PCI: Add PTM clock granularity information
  PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints
  PCI: Add Precision Time Measurement (PTM) support

* pci/demodularize:
  PCI: pciehp: Make explicitly non-modular
  PCI: hotplug: Make core explicitly non-modular
  PCI: xilinx-nwl: Make explicitly non-modular
  PCI: xilinx: Make explicitly non-modular
  PCI: qcom: Make explicitly non-modular
  PCI: dra7xx: Make explicitly non-modular
  PCI/AER: Make explicitly non-modular
  PCI/PME: Make explicitly non-modular
  PCI: Make DPC explicitly non-modular
  PCI: generic: Make explicitly non-modular
  PCI: exynos: Make explicitly non-modular
  PCI: designware: Make explicitly non-modular
  PCI: spear: Make explicitly non-modular
  PCI: portdrv: Make explicitly non-modular
  PCI: imx6: Make explicitly non-modular
  PCI: altera: Make explicitly non-modular
  PCI: altera: Make MSI explicitly non-modular

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>

This code is not being built as a module by anyone:

  obj-$(CONFIG_HOTPLUG_PCI_PCIE)          += pciehp.o
  pciehp-objs                             := pciehp_core.o   \

  drivers/pci/pcie/Kconfig:config HOTPLUG_PCI_PCIE
  drivers/pci/pcie/Kconfig:  bool "PCI Express Hotplug driver"

Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.

Note that for non-modular code, module_init() translates to
device_initcall().  One could argue that we should use subsys_initcall()
here, but for now we stick with runtime equivalence.

We delete module.h but we keep the moduleparam.h include, since we are
keeping the module_param() that the file has as-is for now.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Kristen Carlson Accardi <kristen@linux.intel.com>

This code is not being built as a module by anyone:

  obj-$(CONFIG_HOTPLUG_PCI)           += pci_hotplug.o
  [...]
  pci_hotplug-objs                    := pci_hotplug_core.o

  drivers/pci/hotplug/Kconfig:menuconfig HOTPLUG_PCI
  drivers/pci/hotplug/Kconfig:  bool "Support for PCI Hotplug"

Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.

Remove orphaned exit function in cpci_hotplug_core.c.

Note that for non-modular code, module_init() translates to
device_initcall().  One could argue that we should use subsys_initcall()
here, but for now we stick with runtime equivalence.

We would delete module.h and just keep the moduleparam.h include (since the
file does use module_param), but there is a try_module_get and module_put
pairing that prevents us from doing that.

[bhelgaas: changelog]
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Scott Murray <scott@spiteful.org>
CC: Kristen Carlson Accardi <kristen@linux.intel.com>

This code is not being built as a module by anyone:

  drivers/pci/host/Kconfig:config PCIE_XILINX_NWL
  drivers/pci/host/Kconfig:  bool "NWL PCIe Core"

Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.

Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers.  Delete several functions only used by the remove function.

Note that for non-modular code, builtin_platform_driver() uses the same
init level priority as module_platform_driver(), so this doesn't change
init ordering.

[bhelgaas: changelog]
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <michal.simek@xilinx.com>
CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
CC: Marc Zyngier <marc.zyngier@arm.com>
CC: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>

This code is not being built as a module by anyone:

  drivers/pci/host/Kconfig:config PCIE_XILINX
  drivers/pci/host/Kconfig:  bool "Xilinx AXI PCIe host bridge support"

Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.

Note that for non-modular code, builtin_platform_driver() uses the same
init level priority as module_platform_driver(), so this doesn't change
init ordering.

[bhelgaas: changelog]
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <michal.simek@xilinx.com>
CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>

This code is not being built as a module by anyone:

  drivers/pci/host/Kconfig:config PCIE_QCOM
  drivers/pci/host/Kconfig:  bool "Qualcomm PCIe controller"

Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.

Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
builtin_platform_driver() uses the same init level priority as
module_platform_driver(), so this doesn't change init ordering.

Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers.

[bhelgaas: changelog]
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Stanimir Varbanov <svarbanov@mm-sol.com>

This code is not being built as a module by anyone:

  drivers/pci/host/Kconfig:config PCI_DRA7XX
  drivers/pci/host/Kconfig:  bool "TI DRA7xx PCIe controller"

Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.

Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
builtin_platform_driver_probe() uses the same init level priority as
module_platform_driver_probe(), so this doesn't change init ordering.

Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers.

[bhelgaas: changelog]
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Kishon Vijay Abraham I <kishon@ti.com>