kernel/drivers/pci/hotplug, branch linux-4.3.y

PCI: pciehp: Remove ignored MRL sensor interrupt events

2015-08-10T19:24:09Z

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: Bjorn Helgaas

PCI: pciehp: Remove unused interrupt events

2015-08-10T19:24:09Z

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: Bjorn Helgaas

PCI: pciehp: Handle invalid data when reading from non-existent devices

2015-08-10T19:24:09Z

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=99841 Suggested-by: Bjorn Helgaas Signed-off-by: Jarod Wilson Signed-off-by: Bjorn Helgaas

PCI: pciehp: Simplify pcie_poll_cmd()

2015-07-16T03:03:33Z

Move first slot status read into while to simplify code. Signed-off-by: Yijing Wang Signed-off-by: Bjorn Helgaas

PCI: Use "slot" and "pci_slot" for struct hotplug_slot and struct pci_slot

2015-07-16T03:03:31Z

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: Yijing Wang Signed-off-by: Bjorn Helgaas

PCI: pciehp: Inline the "handle event" functions into the ISR

2015-06-18T21:14:49Z

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: Bjorn Helgaas Reviewed-by: Rajat Jain Acked-by: Yinghai Lu

PCI: pciehp: Rename queue_interrupt_event() to pciehp_queue_interrupt_event()

2015-06-18T21:14:49Z

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: Bjorn Helgaas Reviewed-by: Rajat Jain Acked-by: Yinghai Lu

PCI: pciehp: Make queue_interrupt_event() void

2015-06-18T21:14:49Z

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: Bjorn Helgaas Reviewed-by: Rajat Jain Acked-by: Yinghai Lu

PCI: pciehp: Clean up debug logging

2015-06-17T22:35:28Z

The pciehp debug logging is overly verbose and often redundant. Almost all of the information printed by dbg_ctrl() is also printed by the normal PCI core enumeration code and by pcie_init(). Remove the redundant debug info. When claiming a pciehp bridge, we print the slot characteristics, e.g., Slot #6 AttnBtn- AttnInd- PwrInd- PwrCtrl- MRL- Interlock- NoCompl+ LLActRep+ Add the Hot-Plug Capable and Hot-Plug Surprise bits to this information, and print it all in the same order as lspci does. No functional change except the message text changes. Signed-off-by: Bjorn Helgaas Reviewed-by: Rajat Jain Acked-by: Yinghai Lu

PCI: pciehp: Wait for hotplug command completion where necessary

2015-06-09T15:46:29Z

The commit referenced below deferred waiting for command completion until the start of the next command, allowing hardware to do the latching asynchronously. Unfortunately, being ready to accept a new command is the only indication we have that the previous command is completed. In cases where we need that state change to be enabled, we must still wait for completion. For instance, pciehp_reset_slot() attempts to disable anything that might generate a surprise hotplug on slots that support presence detection. If we don't wait for those settings to latch before the secondary bus reset, we negate any value in attempting to prevent the spurious hotplug. Create a base function with optional wait and helper functions so that pcie_write_cmd() turns back into the "safe" interface which waits before and after issuing a command and add pcie_write_cmd_nowait(), which eliminates the trailing wait for asynchronous completion. The following functions are returned to their previous behavior: pciehp_power_on_slot pciehp_power_off_slot pcie_disable_notification pciehp_reset_slot The rationale is that pciehp_power_on_slot() enables the link and therefore relies on completion of power-on. pciehp_power_off_slot() and pcie_disable_notification() need a wait because data structures may be freed after these calls and continued signaling from the device would be unexpected. And, of course, pciehp_reset_slot() needs to wait for the scenario outlined above. Fixes: 3461a068661c ("PCI: pciehp: Wait for hotplug command completion lazily") Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.17+