1. 24 Aug, 2018 3 commits
    • Lukas Wunner's avatar
      PCI: pciehp: Fix unprotected list iteration in IRQ handler · b5b7417e
      Lukas Wunner authored
      commit 1204e35b upstream.
      Commit b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug
      events for a device") iterates over the devices on a hotplug port's
      subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem.
      It is thus possible for a user to cause a crash by concurrently
      manipulating the device list, e.g. by disabling slot power via sysfs
      on a different CPU or by initiating a remove/rescan via sysfs.
      This can't be fixed by acquiring pci_bus_sem because it may sleep.
      The simplest fix is to avoid the list iteration altogether and just
      check the ignore_hotplug flag on the port itself.  This works because
      pci_ignore_hotplug() sets the flag both on the device as well as on its
      parent bridge.
      We do lose the ability to print the name of the device blocking hotplug
      in the debug message, but that's probably bearable.
      Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lukas Wunner's avatar
      PCI: pciehp: Fix use-after-free on unplug · 2f27dfad
      Lukas Wunner authored
      commit 281e878e upstream.
      When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
      hotplug_slot struct is deregistered and thus freed before freeing the
      IRQ.  The IRQ handler and the work items it schedules print the slot
      name referenced from the freed structure in various informational and
      debug log messages, each time resulting in a quadruple dereference of
      freed pointers (hotplug_slot -> pci_slot -> kobject -> name).
      At best the slot name is logged as "(null)", at worst kernel memory is
      exposed in logs or the driver crashes:
        pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present
      An attacker may provoke the bug by unplugging multiple devices on a
      Thunderbolt daisy chain at once.  Unplugging can also be simulated by
      powering down slots via sysfs.  The bug is particularly easy to trigger
      in poll mode.
      It has been present since the driver's introduction in 2004:
      Fix by rearranging teardown such that the IRQ is freed first.  Run the
      work items queued by the IRQ handler to completion before freeing the
      hotplug_slot struct by draining the work queue from the ->release_slot
      callback which is invoked by pci_hp_deregister().
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.6.4
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lukas Wunner's avatar
      PCI: hotplug: Don't leak pci_slot on registration failure · cf9c2bc5
      Lukas Wunner authored
      commit 4ce64358 upstream.
      If addition of sysfs files fails on registration of a hotplug slot, the
      struct pci_slot as well as the entry in the slot_list is leaked.  The
      issue has been present since the hotplug core was introduced in 2002:
      Perhaps the idea was that even though sysfs addition fails, the slot
      should still be usable.  But that's not how drivers use the interface,
      they abort probe if a non-zero value is returned.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.4.15+
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 03 Aug, 2018 1 commit
    • Lukas Wunner's avatar
      PCI: pciehp: Assume NoCompl+ for Thunderbolt ports · 011626d6
      Lukas Wunner authored
      commit 493fb50e upstream.
      Certain Thunderbolt 1 controllers claim to support Command Completed events
      (value of 0b in the No Command Completed Support field of the Slot
      Capabilities register) but in reality they neither set the Command
      Completed bit in the Slot Status register nor signal a Command Completed
        8086:1513  CV82524  [Light Ridge 4C  2010]
        8086:151a  DSL2310  [Eagle Ridge 2C  2011]
        8086:151b  CVL2510  [Light Peak 2C   2010]
        8086:1547  DSL3510  [Cactus Ridge 4C 2012]
        8086:1548  DSL3310  [Cactus Ridge 2C 2012]
        8086:1549  DSL2210  [Port Ridge 1C   2011]
      All known newer chips (Redwood Ridge and onwards) set No Command Completed
      Support, indicating that they do not support Command Completed events.
      The user-visible impact is that after unplugging such a device, 2 seconds
      elapse until pciehp is unbound.  That's because on ->remove,
      pcie_write_cmd() is called via pcie_disable_notification() and every call
      to pcie_write_cmd() takes 2 seconds (1 second for each invocation of
        [  337.942727] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x1038 (issued 21176 msec ago)
        [  340.014735] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x0000 (issued 2072 msec ago)
      That by itself has always been unpleasant, but the situation has become
      worse with commit cc27b735 ("PCI/portdrv: Turn off PCIe services during
      shutdown"):  Now pciehp is unbound on ->shutdown.  Because Thunderbolt
      controllers typically have 4 hotplug ports, every reboot and shutdown is
      now delayed by 8 seconds, plus another 2 seconds for every attached
      Thunderbolt 1 device.
      Thunderbolt hotplug slots are not physical slots that one inserts cards
      into, but rather logical hotplug slots implemented in silicon.  Devices
      appear beyond those logical slots once a PCI tunnel is established on top
      of the Thunderbolt Converged I/O switch.  One would expect commands written
      to the Slot Control register to be executed immediately by the silicon, so
      for simplicity we always assume NoCompl+ for Thunderbolt ports.
      Fixes: cc27b735 ("PCI/portdrv: Turn off PCIe services during shutdown")
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: stable@vger.kernel.org	# v4.12+
      Cc: Sinan Kaya <okaya@codeaurora.org>
      Cc: Yehezkel Bernat <yehezkel.bernat@intel.com>
      Cc: Michael Jamet <michael.jamet@intel.com>
      Cc: Andreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 03 Jul, 2018 1 commit
  4. 24 Apr, 2018 1 commit
    • Mika Westerberg's avatar
      ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status() · a2b54065
      Mika Westerberg authored
      commit 13d3047c upstream.
      Mike Lothian reported that plugging in a USB-C device does not work
      properly in his Dell Alienware system.  This system has an Intel Alpine
      Ridge Thunderbolt controller providing USB-C functionality.  In these
      systems the USB controller (xHCI) is hotplugged whenever a device is
      connected to the port using ACPI-based hotplug.
      The ACPI description of the root port in question is as follows:
        Device (RP01)
            Name (_ADR, 0x001C0000)
            Device (PXSX)
                Name (_ADR, 0x02)
                Method (_RMV, 0, NotSerialized)
                    // ...
      Here _ADR 0x02 means device 0, function 2 on the bus under root port (RP01)
      but that seems to be incorrect because device 0 is the upstream port of the
      Alpine Ridge PCIe switch and it has no functions other than 0 (the bridge
      itself).  When we get ACPI Notify() to the root port resulting from
      connecting a USB-C device, Linux tries to read PCI_VENDOR_ID from device 0,
      function 2 which of course always returns 0xffffffff because there is no
      such function and we never find the device.
      In Windows this works fine.
      Now, since we get ACPI Notify() to the root port and not to the PXSX device
      we should actually start our scan from there as well and not from the
      non-existent PXSX device.  Fix this by checking presence of the slot itself
      (function 0) if we fail to do that otherwise.
      While there use pci_bus_read_dev_vendor_id() in get_slot_status(), which is
      the recommended way to read Device and Vendor IDs of devices on PCI buses.
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=198557Reported-by: default avatarMike Lothian <mike@fireburn.co.uk>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
      All documentation files were explicitly excluded.
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
         For non */uapi/* files that summary was:
         SPDX license identifier                            # files
         GPL-2.0                                              11139
         and resulted in the first patch in this series.
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                        930
         and resulted in the second patch in this series.
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
         and that resulted in the third patch in this series.
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 24 Aug, 2017 1 commit
  7. 15 Aug, 2017 1 commit
    • Keith Busch's avatar
      PCI: pciehp: Report power fault only once until we clear it · 7612b3b2
      Keith Busch authored
      When a power fault occurs, the power controller sets Power Fault Detected
      in the Slot Status register, and pciehp_isr() queues an INT_POWER_FAULT
      event to handle it.
      It also clears Power Fault Detected, but since nothing has yet changed to
      correct the power fault, the power controller will likely set it again
      immediately, which may cause an infinite loop when pcie_isr() rechecks
      Slot Status.
      Fix that by masking off Power Fault Detected from new events if the driver
      hasn't seen the power fault clear from the previous handling attempt.
      Fixes: fad214b0 ("PCI: pciehp: Process all hotplug events before looking for new ones")
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      [bhelgaas: changelog, pull test out and add comment]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Mayurkumar Patel <mayurkumar.patel@intel.com>
      Cc: stable@vger.kernel.org	# 4.9+
  8. 10 Aug, 2017 2 commits
  9. 02 Aug, 2017 1 commit
  10. 20 Apr, 2017 1 commit
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/pci/hotplug/ · 01b961b7
      David Howells authored
      When the kernel is running in secure boot mode, we lock down the kernel to
      prevent userspace from modifying the running kernel image.  Whilst this
      includes prohibiting access to things like /dev/mem, it must also prevent
      access by means of configuring driver modules in such a way as to cause a
      device to access or modify the kernel image.
      To this end, annotate module_param* statements that refer to hardware
      configuration and indicate for future reference what type of parameter they
      specify.  The parameter parser in the core sees this information and can
      skip such parameters with an error message if the kernel is locked down.
      The module initialisation then runs as normal, but just sees whatever the
      default values for those parameters is.
      Note that we do still need to do the module initialisation because some
      drivers have viable defaults set in case parameters aren't specified and
      some drivers support automatic configuration (e.g. PNP or PCI) in addition
      to manually coded parameters.
      This patch annotates drivers in drivers/pci/hotplug/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      cc: Scott Murray <scott@spiteful.org>
      cc: linux-pci@vger.kernel.org
  11. 30 Mar, 2017 1 commit
  12. 02 Mar, 2017 1 commit
  13. 17 Feb, 2017 3 commits
    • Gavin Shan's avatar
      pci/hotplug/pnv-php: Disable MSI and PCI device properly · 49f4b08e
      Gavin Shan authored
      pnv_php_disable_irq() can be called in two paths: Bailing path in
      pnv_php_enable_irq() or releasing slot. The MSI (or MSIx) interrupts
      is disabled unconditionally in pnv_php_disable_irq(). It's wrong
      because that might be enabled by drivers other than pnv-php.
      This disables MSI (or MSIx) interrupts and the PCI device only if
      it was enabled by pnv-php. In the error path of pnv_php_enable_irq(),
      we rely on the newly added parameter @disable_device. In the path
      of releasing slot, @pnv_php->irq is checked.
      Cc: <stable@vger.kernel.org> # v4.9+
      Fixes: 360aebd8 ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    • Gavin Shan's avatar
      pci/hotplug/pnv-php: Disable surprise hotplug capability on conflicts · 303529d6
      Gavin Shan authored
      The root port or PCIe switch downstream port might have been associated
      with driver other than pnv-php. The MSI or MSIx might also have been
      enabled by that driver (e.g. pcieport_drv). Attempt to enable MSI incurs
      below backtrace:
       PowerPC PowerNV PCI Hotplug Driver version: 0.1
       ------------[ cut here ]------------
       WARNING: CPU: 19 PID: 1004 at drivers/pci/msi.c:1071 \
       NIP [c000000000665c34] __pci_enable_msi_range+0x84/0x4e0
       LR [c000000000665c24] __pci_enable_msi_range+0x74/0x4e0
       Call Trace:
       [c000000384d67600] [c000000000665c24] __pci_enable_msi_range+0x74/0x4e0
       [c000000384d676e0] [d00000000aa31b04] pnv_php_register+0x564/0x5a0 [pnv_php]
       [c000000384d677c0] [d00000000aa31658] pnv_php_register+0xb8/0x5a0 [pnv_php]
       [c000000384d678a0] [d00000000aa31658] pnv_php_register+0xb8/0x5a0 [pnv_php]
       [c000000384d67980] [d00000000aa31dfc] pnv_php_init+0x60/0x98 [pnv_php]
       [c000000384d679f0] [c00000000000cfdc] do_one_initcall+0x6c/0x1d0
       [c000000384d67ab0] [c000000000b92354] do_init_module+0x94/0x254
       [c000000384d67b40] [c00000000019719c] load_module+0x258c/0x2c60
       [c000000384d67d30] [c000000000197bb0] SyS_finit_module+0xf0/0x170
       [c000000384d67e30] [c00000000000b184] system_call+0x38/0xe0
      This fixes the issue by skipping enabling the surprise hotplug
      capability if the MSI or MSIx on the PCI slot's upstream port has
      been enabled by other driver.
      Cc: <stable@vger.kernel.org> # v4.9+
      Fixes: 360aebd8 ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Tested-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    • Gavin Shan's avatar
      pci/hotplug/pnv-php: Remove WARN_ON() in pnv_php_put_slot() · 36c7c9da
      Gavin Shan authored
      The WARN_ON() causes unnecessary backtrace when putting the parent
      slot, which is likely to be NULL.
       WARNING: CPU: 2 PID: 1071 at drivers/pci/hotplug/pnv_php.c:85 \
                                    pnv_php_release+0xcc/0x150 [pnv_php]
       Call Trace:
       [c0000003bc007c10] [d00000000ad613c4] pnv_php_release+0x144/0x150 [pnv_php]
       [c0000003bc007c40] [c0000000006641d8] pci_hp_deregister+0x238/0x330
       [c0000003bc007cd0] [d00000000ad61440] pnv_php_unregister_one+0x70/0xa0 [pnv_php]
       [c0000003bc007d10] [d00000000ad614c0] pnv_php_unregister+0x50/0x80 [pnv_php]
       [c0000003bc007d40] [d00000000ad61e84] pnv_php_exit+0x50/0xcb4 [pnv_php]
       [c0000003bc007d70] [c00000000019499c] SyS_delete_module+0x1fc/0x2a0
       [c0000003bc007e30] [c00000000000b184] system_call+0x38/0xe0
      Cc: <stable@vger.kernel.org> # v4.8+
      Fixes: 66725152 ("PCI/hotplug: PowerPC PowerNV PCI hotplug driver")
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Tested-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  14. 15 Feb, 2017 3 commits
  15. 03 Feb, 2017 1 commit
  16. 14 Jan, 2017 1 commit
    • Peter Zijlstra's avatar
      locking/atomic, kref: Add kref_read() · 2c935bc5
      Peter Zijlstra authored
      Since we need to change the implementation, stop exposing internals.
      Provide kref_read() to read the current reference count; typically
      used for debug messages.
      Kills two anti-patterns:
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  17. 11 Jan, 2017 2 commits
  18. 24 Dec, 2016 1 commit
  19. 12 Dec, 2016 2 commits
  20. 08 Dec, 2016 1 commit
  21. 07 Dec, 2016 1 commit
    • Ashok Raj's avatar
      PCI: pciehp: Prioritize data-link event over presence detect · 385895fe
      Ashok Raj authored
      If Slot Status indicates changes in both Data Link Layer Status and
      Presence Detect, prioritize the Link status change.
      When both events are observed, pciehp currently relies on the Slot Status
      Presence Detect State (PDS) to agree with the Link Status Data Link Layer
      Active status.  The Presence Detect State, however, may be set to 1 through
      out-of-band presence detect even if the link is down, which creates
      conflicting events.
      Since the Link Status accurately reflects the reachability of the
      downstream bus, the Link Status event should take precedence over a
      Presence Detect event.  Skip checking the PDC status if we handled a link
      event in the same handler.
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarKeith Busch <keith.busch@intel.com>
  22. 23 Nov, 2016 1 commit
  23. 18 Nov, 2016 3 commits
    • Lukas Wunner's avatar
      PCI: pciehp: Add runtime PM support for PCIe hotplug ports · 68db9bc8
      Lukas Wunner authored
      Linux 4.8 added support for runtime suspending PCIe ports to D3hot with
      commit 006d44e4 ("PCI: Add runtime PM support for PCIe ports"), but
      excluded hotplug ports.  Those are now afforded runtime PM by the present
      Hotplug ports require a few extra considerations:
      - The configuration space of the port remains accessible in D3hot, so all
        the functions to read or modify the Slot Status and Slot Control
        registers need not be modified.  Even turning on slot power doesn't seem
        to require the port to be in D0, at least the PCIe spec doesn't say so
        and I confirmed that by testing with a Thunderbolt controller.
      - However D0 is required to access devices on the secondary bus.  This
        happens in pciehp_check_link_status() and pciehp_configure_device() (both
        called from board_added()) and in pciehp_unconfigure_device() (called
        from remove_board()), so acquire a runtime PM ref for their invocation.
      - The hotplug port stays active as long as it has active children.  If all
        hotplugged devices below the port runtime suspend, the port is allowed to
        runtime suspend as well.  Plug and unplug detection continues to work in
      - Hotplug interrupts are delivered in-band, so while the hotplug port
        itself is allowed to go to D3hot, its parent ports must stay in D0 for
        interrupts to come through.  Add a corresponding restriction to
      - Runtime PM may only be allowed if the hotplug port is handled natively by
        the OS.  On ACPI systems, the port may alternatively be handled by the
        firmware and things break if the OS puts the port into D3 behind the
        firmware's back:  E.g. Thunderbolt hotplug ports on non-Macs are handled
        by Intel's firmware in System Management Mode and the firmware is known
        to access devices on the port's secondary bus without checking first if
        the port is in D0: https://bugzilla.kernel.org/show_bug.cgi?id=53811Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      CC: Mika Westerberg <mika.westerberg@linux.intel.com>
    • Lukas Wunner's avatar
      ACPI / hotplug / PCI: Make device_is_managed_by_native_pciehp() public · 437eb7bf
      Lukas Wunner authored
      We're about to add runtime PM of hotplug ports, but we need to restrict it
      to ports that are handled natively by the OS:  If they're handled by the
      firmware (which is the case for Thunderbolt on non-Macs), things would
      break if the OS put the ports into D3hot behind the firmware's back.
      To determine if a hotplug port is handled natively, one has to walk up from
      the port to the root bridge and check the cached _OSC Control Field for the
      value of the "PCI Express Native Hot Plug control" bit.  There's already a
      function to do that, device_is_managed_by_native_pciehp(), but it's private
      to drivers/pci/hotplug/acpiphp_glue.c and only compiled in if
      CONFIG_HOTPLUG_PCI_ACPI is enabled.
      Make it public and move it to drivers/pci/pci-acpi.c, so that it is
      available in the more general CONFIG_ACPI case.
      The function contains a check if the device in question is a hotplug port
      and returns false if it's not.  The caller we're going to add doesn't need
      this as it only calls the function if it actually *is* a hotplug port.
      Move the check out of the function into the single existing caller.
      Rename it to pciehp_is_native() and add some kerneldoc and polish.
      No functional change intended.
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    • Lukas Wunner's avatar
      ACPI / hotplug / PCI: Use cached copy of PCI_EXP_SLTCAP_HPC bit · 6ef13824
      Lukas Wunner authored
      We cache the PCI_EXP_SLTCAP_HPC bit in pci_dev->is_hotplug_bridge on device
      probe, so there's no need to read it again when adding the ACPI hotplug
      Here's the call chain to prove that no ordering issue is introduced:
      pci_scan_child_bus [drivers/pci/probe.c]
                  [is_hotplug_bridge bit is set here]
              pcibios_add_bus  [arch/(x86|arm64|ia64)/...]
                acpi_pci_add_bus [drivers/pci/pci-acpi.c]
                  acpiphp_enumerate_slots [drivers/pci/hotplug/acpiphp_glue.c]
                        [is_hotplug_bridge bit is queried here]
      No functional change intended.
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  24. 14 Nov, 2016 1 commit
  25. 31 Oct, 2016 1 commit
    • Paul Gortmaker's avatar
      s390: hotplug: make pci_hpc explicitly non-modular · 0729dcf2
      Paul Gortmaker authored
      The Kconfig currently controlling compilation of this code is:
      drivers/pci/hotplug/Kconfig:config HOTPLUG_PCI_S390
      drivers/pci/hotplug/Kconfig:    bool "System z PCI Hotplug Support"
      ...meaning that it currently is not being built as a module by anyone.
      Lets remove the couple traces of modular infrastructure use, so that
      when reading the driver there is no doubt it is builtin-only.
      We also delete the MODULE_LICENSE tag etc. since all that information
      was (or is now) contained at the top of the file in the comments.
      We don't exchange module.h for init.h or export.h since the file
      does not contain any initcalls or EXPORT of symbols.
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: linux-s390@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  26. 04 Oct, 2016 1 commit
  27. 29 Sep, 2016 2 commits
  28. 22 Sep, 2016 1 commit
    • Keith Busch's avatar
      PCI: pciehp: Allow exclusive userspace control of indicators · 576243b3
      Keith Busch authored
      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"
      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
      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: default avatarKeith Busch <keith.busch@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>