1. 22 7月, 2014 1 次提交
  2. 21 7月, 2014 1 次提交
  3. 16 7月, 2014 2 次提交
  4. 08 7月, 2014 2 次提交
    • F
      PCI: cpqphp: Remove unnecessary null test before debugfs_remove() · 5d37818b
      Fabian Frederick 提交于
      Fix checkpatch warning:
      "WARNING: debugfs_remove(NULL) is safe this check is probably not required"
      Signed-off-by: NFabian Frederick <fabf@skynet.be>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Ryan Desfosses <ryan@desfo.org>
      5d37818b
    • 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
  5. 06 7月, 2014 1 次提交
  6. 27 6月, 2014 1 次提交
    • G
      of: Migrate of_find_node_by_name() users to for_each_node_by_name() · ccdb8ed3
      Grant Likely 提交于
      There are a bunch of users open coding the for_each_node_by_name() by
      calling of_find_node_by_name() directly instead of using the macro. This
      is getting in the way of some cleanups, and the possibility of removing
      of_find_node_by_name() entirely. Clean it up so that all the users are
      consistent.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Takashi Iwai <tiwai@suse.de>
      ccdb8ed3
  7. 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
  8. 17 6月, 2014 2 次提交
  9. 12 6月, 2014 1 次提交
  10. 11 6月, 2014 3 次提交
  11. 28 5月, 2014 6 次提交
  12. 16 5月, 2014 1 次提交
  13. 30 4月, 2014 1 次提交
    • B
      PCI: Remove unnecessary __ref annotations · 10874f5a
      Bjorn Helgaas 提交于
      Some PCI functions used to be marked __devinit.  When CONFIG_HOTPLUG was
      not set, these functions were discarded after boot.  A few callers of these
      __devinit functions were marked __ref to indicate that they could safely
      call the __devinit functions even though the callers were not __devinit.
      
      But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref
      annotations is also gone, so remove them.  Relevant historical commits:
      
        54b956b9 Remove __dev* markings from init.h
        a8e4b9c1 PCI: add generic pci_hp_add_bridge()
        0ab2b57f PCI: fix section mismatch warning in pci_scan_child_bus
        451124a7 PCI: fix 4x section mismatch warnings
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      10874f5a
  14. 26 4月, 2014 1 次提交
    • L
      PCI: rphahp: Fix endianess issues · 761ce533
      Laurent Dufour 提交于
      Numerical values stored in the device tree are encoded in Big Endian and
      should be byte swapped when running in Little Endian.
      
      The RPA hotplug module should convert those values as well.
      
      Note that in rpaphp_get_drc_props(), the comparison between indexes[i+1]
      and *index is done using the BE values (whatever is the current endianess).
      This doesn't matter since we are checking for equality here.  This way only
      the returned value is byte swapped.
      
      RPA also made RTAS calls which implies BE values to be used.  According to
      the patch done in RTAS (http://patchwork.ozlabs.org/patch/336865), no
      additional conversion is required in RPA.
      Signed-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      761ce533
  15. 25 4月, 2014 1 次提交
  16. 15 4月, 2014 3 次提交
  17. 05 3月, 2014 1 次提交
  18. 21 2月, 2014 5 次提交
  19. 20 2月, 2014 2 次提交
  20. 16 2月, 2014 2 次提交
    • R
      ACPI / hotplug / PCI: Add ACPIPHP contexts to devices handled by PCIeHP · cc6254e0
      Rafael J. Wysocki 提交于
      Currently, ACPIPHP does not add hotplug context to devices that
      should be handled by the native PCI hotplug (PCIeHP) code.  The
      reason why was because PCIeHP didn't know about the devices'
      connections with ACPI and would not clean up things properly
      during an eject of an ACPI-backed device, for example.
      
      However, after recent changes that made the ACPI core create struct
      acpi_device objects for all namespace nodes regardless of the
      underlying devices' status and added PCI rescan-remove locking to
      both ACPIPHP and PCIeHP, that concern is not valid any more.
      Namely, after those changes PCIeHP need not care about the ACPI
      side of things any more and it should be serialized with respect to
      ACPIPHP and they won't be running concurrently with each other in
      any case.
      
      For this reason, make ACPIPHP to add its hotplug context to
      all devices with ACPI companions, even the ones that should be
      handled by PCIeHP in principle.  That may work around hotplug
      issues on some systems where PCIeHP is supposed to work, but it
      doesn't and the ACPI hotplug signaling works instead.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cc6254e0
    • R
      ACPI / hotplug / PCI: Rename register_slot() to acpiphp_add_context() · 3799c5a0
      Rafael J. Wysocki 提交于
      The name of register_slot() doesn't really reflect what the function
      is does, so rename it to acpiphp_add_context() and add a proper
      kerneldoc comment to it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3799c5a0