1. 15 9月, 2016 1 次提交
  2. 13 9月, 2016 1 次提交
  3. 21 6月, 2016 1 次提交
    • L
      PCI: pciehp: Ignore interrupts during D3cold · ed91de7e
      Lukas Wunner 提交于
      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>
      ed91de7e
  4. 11 8月, 2015 2 次提交
    • B
      PCI: pciehp: Remove ignored MRL sensor interrupt events · 2db0f71f
      Bjorn Helgaas 提交于
      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>
      2db0f71f
    • J
      PCI: pciehp: Handle invalid data when reading from non-existent devices · 1469d17d
      Jarod Wilson 提交于
      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>
      1469d17d
  5. 16 7月, 2015 1 次提交
  6. 19 6月, 2015 1 次提交
  7. 18 6月, 2015 1 次提交
    • B
      PCI: pciehp: Clean up debug logging · 3784e0c6
      Bjorn Helgaas 提交于
      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: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NRajat Jain <rajatja@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      3784e0c6
  8. 09 6月, 2015 1 次提交
    • A
      PCI: pciehp: Wait for hotplug command completion where necessary · a5dd4b4b
      Alex Williamson 提交于
      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: 3461a068 ("PCI: pciehp: Wait for hotplug command completion lazily")
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.17+
      a5dd4b4b
  9. 24 9月, 2014 3 次提交
    • Y
      PCI: pciehp: Stop disabling notifications during init · 31ff2a5e
      Yinghai Lu 提交于
      During pciehp initialization, we previously wrote two hotplug commands:
      
        pciehp_probe
          pcie_init
            pcie_disable_notification
              pcie_write_cmd           # command 1
          pcie_init_notification
            pcie_enable_notification
              pcie_write_cmd           # command 2
      
      For controllers with errata like Intel CF118, we previously waited for a
      timeout before issuing the second hotplug command because the first command
      only updates interrupt enable bits and is not a "real" hotplug command, so
      the controller doesn't report Command Completed for it.
      
      But there's no need to disable notifications in the first place.  If BIOS
      left them enabled, we could easily take an interrupt before disabling them,
      so there's no benefit in disabling them for the tiny window before we
      enable them.
      
      Drop the unnecessary pcie_disable_notification() call.
      
      [bhelgaas: changelog]
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.htmlSigned-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      31ff2a5e
    • Y
      PCI: pciehp: Add more Slot Control debug output · cf8d7b58
      Yinghai Lu 提交于
      Add more Slot Control debug output and move one print after
      pcie_write_cmd() to be consistent with other debug output.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      cf8d7b58
    • Y
      PCI: pciehp: Fix wait time in timeout message · d433889c
      Yinghai Lu 提交于
      When we warned about a timeout on a hotplug command, we previously printed
      the time between calls to pcie_write_cmd(), without accounting for any time
      spent actually waiting.  Consider this sequence:
      
        pcie_write_cmd
          write SLTCTL
          cmd_started = jiffies          # T1
      
        pcie_write_cmd
          pcie_wait_cmd
            now = jiffies                # T2
            wait_event_timeout           # we may wait here
            if (timeout)
              ctrl_info("Timeout on command issued %u msec ago",
                        jiffies_to_msecs(now - cmd_started))
      
      We previously printed (T2 - T1), but that doesn't include the time spent in
      wait_event_timeout().
      
      Fix this by using the current jiffies value, not the one cached before
      calling wait_event_timeout().
      
      [bhelgaas: changelog, use current jiffies instead of adding timeout]
      Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time")
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d433889c
  10. 23 9月, 2014 1 次提交
  11. 13 9月, 2014 1 次提交
  12. 11 9月, 2014 1 次提交
    • B
      PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device · b440bde7
      Bjorn Helgaas 提交于
      Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold),
      normally generates a hot-remove event that unbinds the driver.
      
      Some drivers expect to remain bound to a device even while they power it
      off and back on again.  This can be dangerous, because if the device is
      removed or replaced while it is powered off, the driver doesn't know that
      anything changed.  But some drivers accept that risk.
      
      Add pci_ignore_hotplug() for use by drivers that know their device cannot
      be removed.  Using pci_ignore_hotplug() tells the PCI core that hot-plug
      events for the device should be ignored.
      
      The radeon and nouveau drivers use this to switch between a low-power,
      integrated GPU and a higher-power, higher-performance discrete GPU.  They
      power off the unused GPU, but they want to remain bound to it.
      
      This is a reimplementation of f244d8b6 ("ACPIPHP / radeon / nouveau:
      Fix VGA switcheroo problem related to hotplug") but extends it to work with
      both acpiphp and pciehp.
      
      This fixes a problem where systems with dual GPUs using the radeon drivers
      become unusable, freezing every few seconds (see bugzillas below).  The
      resume of the radeon device may also fail, e.g.,
      
      This fixes problems on dual GPU systems where the radeon driver becomes
      unusable because of problems while suspending the device, as in bug 79701:
      
          [drm] radeon: finishing device.
          radeon 0000:01:00.0: Userspace still has active objects !
          radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free
          ...
          WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]()
          trying to unbind memory from uninitialized GART !
      
      or while resuming it, as in bug 77261:
      
          radeon 0000:01:00.0: ring 0 stalled for more than 10158msec
          radeon 0000:01:00.0: GPU lockup ...
          radeon 0000:01:00.0: GPU pci config reset
          pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1)
          radeon 0000:01:00.0: GPU reset succeeded, trying to resume
          *ERROR* radeon: dpm resume failed
          radeon 0000:01:00.0: Wait for MC idle timedout !
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701Reported-by: NShawn Starr <shawn.starr@rogers.com>
      Reported-by: NJose P. <lbdkmjdf@sharklasers.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Acked-by: NRajat Jain <rajatxjain@gmail.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NDave Airlie <airlied@redhat.com>
      CC: stable@vger.kernel.org	# v3.15+
      b440bde7
  13. 08 7月, 2014 1 次提交
    • M
      PCI: pciehp: Clear Data Link Layer State Changed during init · 0d25d35c
      Myron Stowe 提交于
      During PCIe hot-plug initialization - pciehp_probe() - data structures
      related to slot capabilities are set up.  As part of this set up, ISRs are
      put in place to handle slot events and all event bits are cleared out.
      
      This patch adds the Data Link Layer State Changed (PCI_EXP_SLTSTA_DLLSC)
      Slot Status bit to the event bits that are cleared out during
      initialization.
      
      If the BIOS doesn't clear DLLSC before handoff to the OS, pciehp notices
      that it's set and interprets it as a new Link Up event, which results in
      spurious messages:
      
        pciehp 0000:82:04.0:pcie24: slot(4): Link Up event
        pciehp 0000:82:04.0:pcie24: Device 0000:83:00.0 already exists at 0000:83:00, cannot hot-add
        pciehp 0000:82:04.0:pcie24: Cannot add device at 0000:83:00
      
      Prior to e48f1b67 ("PCI: pciehp: Use link change notifications for
      hot-plug and removal"), pciehp ignored DLLSC.
      
      Reference:
        PCI-SIG.  PCI Express Base Specification Revision 4.0 Version 0.3
        (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah).
      
      [bhelgaas: add e48f1b67 ref and stable tag]
      Fixes: e48f1b67 ("PCI: pciehp: Use link change notifications for hot-plug and removal")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79611Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.15+
      0d25d35c
  14. 06 7月, 2014 1 次提交
  15. 18 6月, 2014 3 次提交
    • B
      PCI: pciehp: Remove assumptions about which commands cause completion events · 2cc56f30
      Bjorn Helgaas 提交于
      We use incorrect logic to decide whether a PCIe hotplug controller
      generates command completion events.
      
      5808639b ("pciehp: fix slow probing") assumed that the Slot Status
      "Command Completed" bit was set only for commands affecting slot power,
      indicators, or electromechanical interlock.  That assumption is false: per
      sec. 6.7.3.2 of PCIe spec r3.0, a write targeting any portion of the Slot
      Control register is a command, and (if command completed events are
      supported) software must wait for a command to complete before issuing the
      next command.
      
      5808639b was to fix boot-time timeouts (see bugzilla below) on a Lenovo
      Thinkpad R61 with an Intel hotplug controller.  The controller probably has
      the Intel CF118 erratum, which means it doesn't report Command Completed
      unless the Slot Control power, indicator, or interlock bits are changed.
      This causes a timeout because pciehp always waits for Command Complete (if
      supported), regardless of which bits are changed.
      
      Remove the incorrect logic because the timeouts have been addressed
      differently by these changes:
      
        PCI: pciehp: Wait for hotplug command completion lazily
        PCI: pciehp: Compute timeout from hotplug command start time
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=10751
      Tested-by: Rajat Jain <rajatxjain@gmail.com>	(IDT 807a controller)
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      2cc56f30
    • B
      PCI: pciehp: Compute timeout from hotplug command start time · 40b96083
      Bjorn Helgaas 提交于
      If we issue a hotplug command, go do something else, then come back and
      wait for the command to complete, we don't have to wait the whole timeout
      period, because some of it elapsed while we were doing something else.
      
      Keep track of the time we issued the command, and wait only until the
      timeout period from that point has elapsed.
      
      For controllers with errata like Intel CF118, we previously timed out
      before issuing the second hotplug command:
      
        At time T1 (during boot):
          - Write DLLSCE, ABPE, PDCE, etc. to Slot Control
        At time T2 (hotplug event):
          - Wait for command completion (CC) in Slot Status
          - Timeout at T2 + 1 second because CC is never set in Slot Status
          - Write PCC, PIC, etc. to Slot Control
      
      With this change, we wait until T1 + 1 second instead of T2 + 1 second.
      If the hotplug event is more than 1 second after the boot-time
      initialization, we won't wait for the timeout at all.
      
      We still emit a "Timeout on hotplug command" message if it timed out; we
      should see this on the first hotplug event on every controller with this
      erratum, as well as on real errors on controllers without the erratum.
      
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html
      Tested-by: Rajat Jain <rajatxjain@gmail.com>	(IDT 807a controller)
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      40b96083
    • B
      PCI: pciehp: Wait for hotplug command completion lazily · 3461a068
      Bjorn Helgaas 提交于
      Previously we issued a hotplug command and waited for it to complete.  But
      there's no need to wait until we're ready to issue the *next* command.  The
      next command will probably be much later, so the first one may have already
      completed and we may not have to actually wait at all.
      
      Because of hardware errata, some controllers generate command completion
      events for some commands but not others.  In the case of Intel CF118 (see
      spec update reference), the controller indicates command completion only
      for Slot Control writes that change the value of the following bits:
      
        Power Controller Control
        Power Indicator Control
        Attention Indicator Control
        Electromechanical Interlock Control
      
      Changes to other bits, e.g., the interrupt enable bits, do not cause the
      Command Completed bit to be set.  Controllers from AMD and Nvidia are
      reported to have similar errata.
      
      These errata cause timeouts when pcie_enable_notification() enables
      interrupts.  Previously that timeout occurred at boot-time.  With this
      change, the timeout occurs later, when we change the state of the slot
      power, indicators, or interlock.  This speeds up boot but causes a timeout
      at the first hotplug event on the slot.  Subsequent events don't timeout
      because only the first (boot-time) hotplug command updates Slot Control
      without touching the power/indicator/interlock controls.
      
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html
      Tested-by: Rajat Jain <rajatxjain@gmail.com>	(IDT 807a controller)
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      3461a068
  16. 17 6月, 2014 1 次提交
  17. 11 6月, 2014 2 次提交
  18. 25 4月, 2014 1 次提交
  19. 20 2月, 2014 1 次提交
  20. 12 2月, 2014 4 次提交
  21. 11 2月, 2014 2 次提交
  22. 16 12月, 2013 7 次提交
  23. 15 12月, 2013 1 次提交
  24. 15 11月, 2013 1 次提交