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>

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>

Clear the LED attention status after a successful device add.  It is
possible the attention LED was on from a previous power fault or link
failure, and a subsequent successful device insert insertion should clear
it.
Signed-off-by: NKeith Busch <keith.busch@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If a PCI bridge (or PCIe port) that is runtime-suspended gets an ACPI
hotplug notification, such as a bus check, it has to be resumed before
re-scanning the devices below it, or those devices will not be
accessible and will be treated as hot-removed.

Make that happen and let the bridge suspend again after the bus below it
has been re-scanned.

This is a replacement for commit 16468c78 ("ACPI / hotplug / PCI:
Runtime resume bridge before rescan") that has been reverted, because it
introduced a system resume regression (due to missing bridge->pci_dev
checks that are necessary in case the notification is targeted at the
host bridge) and it is necessary for the code added by commit
006d44e4 ("PCI: Add runtime PM support for PCIe ports") to work as
expected.
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 16468c78.

Bisection showed that it was the root cause for a resume hang on a
bog-standard all-Intel laptop (Sony Vaio Pro 11), and reverting fixes
the hang.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The underlying slot hotplug registration code assumed multiple slots, but
the actual implementation is broken for multiple slots.

This went unnoticed for years do to the fact that PowerVM seems to only
ever provide a single hotplug slot per PHB.

Under qemu/kvm the hotplug slot model aligns more with x86 where
multiple slots are presented under a single PHB. As seen in the
following each additional slot after the first fails to register due to
each slot always being compared against the first child node of the PHB
in the device tree.

  rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
  rpaphp: Slot [Slot 0] registered
  rpaphp: pci_hp_register failed with error -16
  rpaphp: pci_hp_register failed with error -16
  rpaphp: pci_hp_register failed with error -16
  rpaphp: pci_hp_register failed with error -16

The registration logic is fixed so that each slot is compared
against the existing child devices of the PHB in the device tree to
determine present slots vs empty slots.

  rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
  rpaphp: Slot [C0] registered
  rpaphp: Slot [C1] registered
  rpaphp: Slot [C2] registered
  rpaphp: Slot [C3] registered
  rpaphp: Slot [C4] registered
Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
Reviewed-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
[mpe: Massage changelog]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

When calling pnv_php_set_slot_power_state() with state ==
OPAL_PCI_SLOT_OFFLINE, remove devices from the device tree as if we're
dealing with OPAL_PCI_SLOT_POWER_OFF.

Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The cxl driver will use infrastructure from pnv_php to handle device tree
updates when switching bi-modal CAPI cards into CAPI mode.

To enable this, export pnv_php_find_slot() and
pnv_php_set_slot_power_state(), and add corresponding declarations, as well
as the definition of struct pnv_php_slot, to asm/pnv-pci.h.

Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
Acked-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

This adds standalone driver to support PCI hotplug for PowerPC PowerNV
platform that runs on top of skiboot firmware. The firmware identifies
hotpluggable slots and marked their device tree node with proper
"ibm,slot-pluggable" and "ibm,reset-by-firmware". The driver scans
device tree nodes to create/register PCI hotplug slot accordingly.

The PCI slots are organized in fashion of tree, which means one
PCI slot might have parent PCI slot and parent PCI slot possibly
contains multiple child PCI slots. At the plugging time, the parent
PCI slot is populated before its children. The child PCI slots are
removed before their parent PCI slot can be removed from the system.

If the skiboot firmware doesn't support slot status retrieval, the PCI
slot device node shouldn't have property "ibm,reset-by-firmware". In
that case, none of valid PCI slots will be detected from device tree.
The skiboot firmware doesn't export the capability to access attention
LEDs yet and it's something for TBD.
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>

If a hotplug port is suspended to D3cold, its slot status register cannot
be read.  If that hotplug port happens to share its IRQ with other devices,
whenever an interrupt occurs for one of these devices, pciehp logs a
"no response from device" message and tries to read the PCI_EXP_SLTSTA
register, even though we know that will fail.

Ignore interrupts while we're in D3cold.

[bhelgaas: changelog]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If a PCI bridge (or PCIe port) that is runtime suspended gets an ACPI
hotplug event, such as BUS_CHECK we need to make sure it is resumed before
devices below the bridge are re-scanned. Otherwise the devices behind the
port are not accessible and will be treated as hot-unplugged.

To fix this, resume PCI bridges from runtime suspend while rescanning.
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>

This renames pcibios_find_pci_bus() to pci_find_bus_by_node() to
avoid conflicts with those PCI subsystem weak function names, which
have prefix "pcibios". No logical changes introduced.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

This renames pcibios_{add,remove}_pci_devices() to avoid conflicts
with names of the weak functions in PCI subsystem, which have the
prefix "pcibios". No logical changes introduced.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-By: NAlistair Popple <alistair@popple.id.au>
Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

If ibm_get_table_from_acpi() fails then "table" isn't initialized.  Check
for failure so we don't reference "table" unless it's been initialized.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

For each PCI function we need to maintain arch specific data in
struct zpci_dev which also contains a pointer to struct pci_dev.

When a function is registered or deregistered (which is triggered by PCI
common code) we need to adjust that pointer which could interfere with
the machine check handler (triggered by FW) using zpci_dev->pdev.

Since multiple instances of the same pdev could exist at a time this can't
be solved with locking.

Fix that by ditching the pdev pointer and use a bus walk to reach
struct pci_dev (only one instance of a pdev can be registered at the bus
at a time).
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

In acpiphp_enable_slot(), there is a missing unlock path
when error occurred.  It needs to be unlocked before returning
an error.
Signed-off-by: NInsu Yun <wuninsu@gmail.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Remove unneeded NULL test.  The index variable of list_for_each_entry is
never NULL, as it is the structure that contains the list pointer.

Generated by: scripts/coccinelle/iterators/itnull.cocci
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Geliang Tang <geliangtang@163.com>

Use list_for_each_entry() instead of list_for_each() to simplify the code.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

ibm_slot_from_id() can return null if the des header signature is not
"aPCI" or if the kmalloc() for the return ACPI descriptor fails, causing
potential null pointer dereferences on the return null descriptor.

Handle the null case with appropriate check and error return.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The hpc_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>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use to_pci_dev() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Fix all whitespace issues (missing or needed whitespace) in all files in
drivers/pci.  Code is compiled with allyesconfig before and after code
changes and objects are recorded and checked with objdiff and they are not
changed after this commit.
Signed-off-by: NBogicevic Sasa <brutallesale@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Bit 7 of the "Header Type" register indicates a multi-function device when
set.  Bits 0-6 contain encoded values, where 0x1 indicates a PCI-PCI
bridge.  It is incorrect to test this as though it were a mask.

For example, while the PCI 3.0 spec only defines values 0x0, 0x1, and 0x2,
it's conceivable that a future spec could define 0x3 to mean something
else; then tests for "(hdr_type & 0x7f) & PCI_HEADER_TYPE_BRIDGE" would
incorrectly succeed for this new 0x3 header type.

Test bits 0-6 of the Header Type for equality with PCI_HEADER_TYPE_BRIDGE.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When called from pciehp_sysfs_disable_slot(), the call to
pciehp_disable_slot() was not protected by the hotplug mutex.

Hold slot->hotplug_lock while calling pciehp_disable_slot().
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRajat Jain <rajatxjain@gmail.com>

Up to now, work items to be queued to be handled by pciehp_power_thread()
are allocated using kmalloc() in three different locations.  If not needed,
kfree() is called to free the allocated data.

Introduce a separate function to allocate the work item and queue it, and
call it only if needed.  This reduces code duplication and avoids having to
free memory if the work item does not need to get executed.

[bhelgaas: tweak "no memory" message, make pciehp_queue_power_work() static]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

We queued interrupt events for the MRL being opened or closed, but the code
in interrupt_event_handler() that handles these events ignored them.

Stop enabling MRL interrupts and remove the ignored events.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The list of interrupt events (INT_BUTTON_IGNORE, INT_PRESENCE_ON, etc.) was
copied from other hotplug drivers, but pciehp doesn't use them all.

Remove the interrupt events that aren't used by pciehp.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

It's platform-dependent, but an MMIO read to a non-existent PCI device
generally returns data with all bits set.  This happens when the host
bridge or Root Complex times out waiting for a response from the device and
fabricates return data to complete the CPU's read.

One example, reported in the bugzilla below, involved this hierarchy:

  pci 0000:00:1c.0: PCI bridge to [bus 02-3a] Root Port
  pci 0000:02:00.0: PCI bridge to [bus 03-0a] Upstream Port
  pci 0000:03:03.0: PCI bridge to [bus 05-07] Downstream Port
  pci 0000:05:00.0: PCI bridge to [bus 06-07] Thunderbolt Upstream Port
  pci 0000:06:00.0: PCI bridge to [bus 07]    Thunderbolt Downstream Port
  pci 0000:07:00.0: BCM57762 NIC

Unplugging the Thunderbolt switch and the NIC below it resulted in this:

  pciehp 0000:03:03.0: Surprise Removal
  tg3 0000:07:00.0: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
  pciehp 0000:06:00.0: unloading service driver pciehp
  pciehp 0000:06:00.0: pcie_isr: intr_loc 11f
  pciehp 0000:06:00.0: Switch interrupt received
  pciehp 0000:06:00.0: Latch open on Slot
  pciehp 0000:06:00.0: Attention button interrupt received
  pciehp 0000:06:00.0: Button pressed on Slot
  pciehp 0000:06:00.0: Presence/Notify input change
  pciehp 0000:06:00.0: Card present on Slot
  pciehp 0000:06:00.0: Power fault interrupt received
  pciehp 0000:06:00.0: Data Link Layer State change
  pciehp 0000:06:00.0: Link Up event

The pciehp driver correctly noticed that the Thunderbolt switch (05:00.0
and 06:00.0) and NIC (07:00.0) had been removed, and it called their driver
remove methods.

Since the NIC was already gone, tg3 received 0xffffffff when it tried to
read from the device.  The resulting timeout is a tg3 issue and not of
interest here.

Similarly, since the 06:00.0 Thunderbolt switch was already gone,
pcie_isr() received 0xffff when it tried to read PCI_EXP_SLTSTA, and pciehp
thought that was valid status showing that many events had happened: the
latch had been opened, the attention button had been pressed, a card was
now present, and the link was now up.  These are all wrong, of course, but
pciehp went on to try to power up and enumerate devices below the
non-existent bridge:

  pciehp 0000:06:00.0: PCI slot - powering on due to button press
  pciehp 0000:06:00.0: Surprise Insertion
  pci 0000:07:00.0 id reading try 50 times with interval 20 ms to get ffffffff

[bhelgaas: changelog, also check in pcie_poll_cmd() & pcie_do_write_cmd()]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99841Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Move first slot status read into while to simplify code.
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Now in pci_hotplug_core.c, we randomly name a struct hotplug_slot and a
struct pci_slot.  It's easy to confuse them, so let us use "slot" for a
struct hotplug_slot and "pci_slot" for a struct pci_slot.

No functional change.
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The pciehp_handle_*() functions (pciehp_handle_attention_button(), etc.)
only contain a line or two of useful code, so it's clumsy to put
them in separate functions.  All they so is add an event to a work queue,
and it's clearer to see that directly in the ISR.

Inline them directly into pcie_isr().  No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRajat Jain <rajatja@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Rename queue_interrupt_event() to pciehp_queue_interrupt_event() so we can
make it extern and call it from pcie_isr().

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRajat Jain <rajatja@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Nobody looks at the return value from queue_interrupt_event(), so errors
were silently ignored.  Convert it to a "void" function and note the error
in the dmesg log.

No functional change except the new message.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRajat Jain <rajatja@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>