1. 18 Sep, 2018 3 commits
    • Lukas Wunner's avatar
      PCI: hotplug: Embed hotplug_slot · 125450f8
      Lukas Wunner authored
      When the PCI hotplug core and its first user, cpqphp, were introduced in
      February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot
      struct for its internal use plus a hotplug_slot struct to be registered
      with the hotplug core and linked the two with pointers:
      https://git.kernel.org/tglx/history/c/a8a2069f432c
      
      Nowadays, the predominant pattern in the tree is to embed ("subclass")
      such structures in one another and cast to the containing struct with
      container_of().  But it wasn't until July 2002 that container_of() was
      introduced with historic commit ec4f214232cf:
      https://git.kernel.org/tglx/history/c/ec4f214232cf
      
      pnv_php, introduced in 2016, did the right thing and embedded struct
      hotplug_slot in its internal struct pnv_php_slot, but all other drivers
      cargo-culted cpqphp's design and linked separate structs with pointers.
      
      Embedding structs is preferrable to linking them with pointers because
      it requires fewer allocations, thereby reducing overhead and simplifying
      error paths.  Casting an embedded struct to the containing struct
      becomes a cheap subtraction rather than a dereference.  And having fewer
      pointers reduces the risk of them pointing nowhere either accidentally
      or due to an attack.
      
      Convert all drivers to embed struct hotplug_slot in their internal slot
      struct.  The "private" pointer in struct hotplug_slot thereby becomes
      unused, so drop it.
      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>
      Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>  # drivers/pci/hotplug/rpa*
      Acked-by: Sebastian Ott <sebott@linux.ibm.com>        # drivers/pci/hotplug/s390*
      Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
      Cc: Len Brown <lenb@kernel.org>
      Cc: Scott Murray <scott@spiteful.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
      Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Corentin Chary <corentin.chary@gmail.com>
      Cc: Darren Hart <dvhart@infradead.org>
      125450f8
    • Lukas Wunner's avatar
      PCI: hotplug: Drop hotplug_slot_info · a7da2161
      Lukas Wunner authored
      Ever since the PCI hotplug core was introduced in 2002, drivers had to
      allocate and register a struct hotplug_slot_info for every slot:
      https://git.kernel.org/tglx/history/c/a8a2069f432c
      
      Apparently the idea was that drivers furnish the hotplug core with an
      up-to-date card presence status, power status, latch status and
      attention indicator status as well as notify the hotplug core of changes
      thereof.  However only 4 out of 12 hotplug drivers bother to notify the
      hotplug core with pci_hp_change_slot_info() and the hotplug core never
      made any use of the information:  There is just a single macro in
      pci_hotplug_core.c, GET_STATUS(), which uses the hotplug_slot_info if
      the driver lacks the corresponding callback in hotplug_slot_ops.  The
      macro is called when the user reads the attribute via sysfs.
      
      Now, if the callback isn't defined, the attribute isn't exposed in sysfs
      in the first place (see e.g. has_power_file()).  There are only two
      situations when the hotplug_slot_info would actually be accessed:
      
      * If the driver defines ->enable_slot or ->disable_slot but not
        ->get_power_status.
      
      * If the driver defines ->set_attention_status but not
        ->get_attention_status.
      
      There is no driver doing the former and just a single driver doing the
      latter, namely pnv_php.c.  Amend it with a ->get_attention_status
      callback.  With that, the hotplug_slot_info becomes completely unused by
      the PCI hotplug core.  But a few drivers use it internally as a cache:
      
      cpcihp uses it to cache the latch_status and adapter_status.
      cpqhp uses it to cache the adapter_status.
      pnv_php and rpaphp use it to cache the attention_status.
      shpchp uses it to cache all four values.
      
      Amend these drivers to cache the information in their private slot
      struct.  shpchp's slot struct already contains members to cache the
      power_status and adapter_status, so additional members are only needed
      for the other two values.  In the case of cpqphp, the cached value is
      only accessed in a single place, so instead of caching it, read the
      current value from the hardware.
      
      Caution:  acpiphp, cpci, cpqhp, shpchp, asus-wmi and eeepc-laptop
      populate the hotplug_slot_info with initial values on probe.  That code
      is herewith removed.  There is a theoretical chance that the code has
      side effects without which the driver fails to function, e.g. if the
      ACPI method to read the adapter status needs to be executed at least
      once on probe.  That seems unlikely to me, still maintainers should
      review the changes carefully for this possibility.
      
      Rafael adds: "I'm not aware of any case in which it will break anything,
      [...] but if that happens, it may be necessary to add the execution of
      the control methods in question directly to the initialization part."
      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>
      Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>  # drivers/pci/hotplug/rpa*
      Acked-by: Sebastian Ott <sebott@linux.ibm.com>        # drivers/pci/hotplug/s390*
      Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
      Cc: Len Brown <lenb@kernel.org>
      Cc: Scott Murray <scott@spiteful.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
      Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Corentin Chary <corentin.chary@gmail.com>
      Cc: Darren Hart <dvhart@infradead.org>
      a7da2161
    • Lukas Wunner's avatar
      PCI: hotplug: Constify hotplug_slot_ops · 81c4b5bf
      Lukas Wunner authored
      Hotplug drivers cannot declare their hotplug_slot_ops const, making them
      attractive targets for attackers, because upon registration of a hotplug
      slot, __pci_hp_initialize() writes to the "owner" and "mod_name" members
      in that struct.
      
      Fix by moving these members to struct hotplug_slot and constify every
      driver's hotplug_slot_ops except for pciehp.
      
      pciehp constructs its hotplug_slot_ops at runtime based on the PCIe
      port's capabilities, hence cannot declare them const.  It can be
      converted to __write_rarely once that's mainlined:
      http://www.openwall.com/lists/kernel-hardening/2016/11/16/3Signed-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>
      Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>  # drivers/pci/hotplug/rpa*
      Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
      Cc: Len Brown <lenb@kernel.org>
      Cc: Scott Murray <scott@spiteful.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
      Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Corentin Chary <corentin.chary@gmail.com>
      Cc: Darren Hart <dvhart@infradead.org>
      81c4b5bf
  2. 23 Jul, 2018 1 commit
    • Lukas Wunner's avatar
      PCI: hotplug: Demidlayer registration with the core · 51bbf9be
      Lukas Wunner authored
      When a hotplug driver calls pci_hp_register(), all steps necessary for
      registration are carried out in one go, including creation of a kobject
      and addition to sysfs.  That's a problem for pciehp once it's converted
      to enable/disable the slot exclusively from the IRQ thread:  The thread
      needs to be spawned after creation of the kobject (because it uses the
      kobject's name), but before addition to sysfs (because it will handle
      enable/disable requests submitted via sysfs).
      
      pci_hp_deregister() does offer a ->release callback that's invoked
      after deletion from sysfs and before destruction of the kobject.  But
      because pci_hp_register() doesn't offer a counterpart, hotplug drivers'
      ->probe and ->remove code becomes asymmetric, which is error prone
      as recently discovered use-after-free bugs in pciehp's ->remove hook
      have shown.
      
      In a sense, this appears to be a case of the midlayer antipattern:
      
         "The core thesis of the "midlayer mistake" is that midlayers are
          bad and should not exist.  That common functionality which it is
          so tempting to put in a midlayer should instead be provided as
          library routines which can [be] used, augmented, or ignored by
          each bottom level driver independently.  Thus every subsystem
          that supports multiple implementations (or drivers) should
          provide a very thin top layer which calls directly into the
          bottom layer drivers, and a rich library of support code that
          eases the implementation of those drivers.  This library is
          available to, but not forced upon, those drivers."
              --  Neil Brown (2009), https://lwn.net/Articles/336262/
      
      The presence of midlayer traits in the PCI hotplug core might be ascribed
      to its age:  When it was introduced in February 2002, the blessings of a
      library approach might not have been well known:
      https://git.kernel.org/tglx/history/c/a8a2069f432c
      
      For comparison, the driver core does offer split functions for creating
      a kobject (device_initialize()) and addition to sysfs (device_add()) as
      an alternative to carrying out everything at once (device_register()).
      This was introduced in October 2002:
      https://git.kernel.org/tglx/history/c/8b290eb19962
      
      The odd ->release callback in the PCI hotplug core was added in 2003:
      https://git.kernel.org/tglx/history/c/69f8d663b595
      
      Clearly, a library approach would not force every hotplug driver to
      implement a ->release callback, but rather allow the driver to remove
      the sysfs files, release its data structures and finally destroy the
      kobject.  Alternatively, a driver may choose to remove everything with
      pci_hp_deregister(), then release its data structures.
      
      To this end, offer drivers pci_hp_initialize() and pci_hp_add() as a
      split-up version of pci_hp_register().  Likewise, offer pci_hp_del()
      and pci_hp_destroy() as a split-up version of pci_hp_deregister().
      
      Eliminate the ->release callback and move its code into each driver's
      teardown routine.
      
      Declare pci_hp_deregister() void, in keeping with the usual kernel
      pattern that enablement can fail, but disablement cannot.  It only
      returned an error if the caller passed in a NULL pointer or a slot which
      has never or is no longer registered or is sharing its name with another
      slot.  Those would be bugs, so WARN about them.  Few hotplug drivers
      actually checked the return value and those that did only printed a
      useless error message to dmesg.  Remove that.
      
      For most drivers the conversion was straightforward since it doesn't
      matter whether the code in the ->release callback is executed before or
      after destruction of the kobject.  But in the case of ibmphp, it was
      unclear to me whether setting slot_cur->ctrl and slot_cur->bus_on to
      NULL needs to happen before the kobject is destroyed, so I erred on
      the side of caution and ensured that the order stays the same.  Another
      nontrivial case is pnv_php, I've found the list and kref logic difficult
      to understand, however my impression was that it is safe to delete the
      list element and drop the references until after the kobject is
      destroyed.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>  # drivers/platform/x86
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Scott Murray <scott@spiteful.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Corentin Chary <corentin.chary@gmail.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: Andy Shevchenko <andy@infradead.org>
      51bbf9be
  3. 04 Jun, 2018 2 commits
  4. 02 Jun, 2018 3 commits
  5. 28 Jan, 2018 1 commit
  6. 18 Nov, 2016 1 commit
    • 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>
      437eb7bf
  7. 13 Nov, 2014 1 commit
  8. 13 Sep, 2014 1 commit
  9. 07 Dec, 2013 1 commit
    • Lv Zheng's avatar
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng authored
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  10. 14 Nov, 2013 1 commit
  11. 14 Aug, 2013 1 commit
  12. 31 Jul, 2013 1 commit
  13. 17 Apr, 2013 1 commit
  14. 31 Oct, 2011 1 commit
    • Paul Gortmaker's avatar
      include: convert various register fcns to macros to avoid include chaining · eb5589a8
      Paul Gortmaker authored
      The original implementations reference THIS_MODULE in an inline.
      We could include <linux/export.h>, but it is better to avoid chaining.
      
      Fortunately someone else already thought of this, and made a similar
      inline into a #define in <linux/device.h> for device_schedule_callback(),
      [see commit 523ded71] so follow that precedent here.
      
      Also bubble up any __must_check that were used on the prev. wrapper inline
      functions up one to the real __register functions, to preserve any prev.
      sanity checks that were used in those instances.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      eb5589a8
  15. 23 Feb, 2010 2 commits
  16. 15 Sep, 2009 3 commits
  17. 14 Sep, 2009 1 commit
  18. 09 Sep, 2009 1 commit
  19. 18 Jun, 2009 1 commit
  20. 16 Jun, 2009 2 commits
  21. 07 Jan, 2009 1 commit
    • Kenji Kaneshige's avatar
      PCI hotplug: introduce functions for ACPI slot detection · e8c331e9
      Kenji Kaneshige authored
      Some ACPI related PCI hotplug code can be shared among PCI hotplug
      drivers. This patch introduces the following functions in
      drivers/pci/hotplug/acpi_pcihp.c to share the code, and changes
      acpiphp and pciehp to use them.
      
      - int acpi_pci_detect_ejectable(struct pci_bus *pbus)
        This checks if the specified PCI bus has ejectable slots.
      
      - int acpi_pci_check_ejectable(struct pci_bus *pbus, acpi_handle handle)
        This checks if the specified handle is ejectable ACPI PCI slot. The
        'pbus' parameter is needed to check if 'handle' is PCI related ACPI
        object.
      
      This patch also introduces the following inline function in
      include/linux/pci-acpi.h, which is useful to get ACPI handle of the
      PCI bridge from struct pci_bus of the bridge's secondary bus.
      
      - static inline acpi_handle acpi_pci_get_bridge_handle(struct pci_bus *pbus)
        This returns ACPI handle of the PCI bridge which generates PCI bus
        specified by 'pbus'.
      Signed-off-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      e8c331e9
  22. 31 Dec, 2008 1 commit
  23. 22 Oct, 2008 3 commits
  24. 10 Jun, 2008 2 commits
    • Alex Chiang's avatar
      PCI: introduce pci_slot · f46753c5
      Alex Chiang authored
      Currently, /sys/bus/pci/slots/ only exposes hotplug attributes when a
      hotplug driver is loaded, but PCI slots have attributes such as address,
      speed, width, etc.  that are not related to hotplug at all.
      
      Introduce pci_slot as the primary data structure and kobject model.
      Hotplug attributes described in hotplug_slot become a secondary
      structure associated with the pci_slot.
      
      This patch only creates the infrastructure that allows the separation of
      PCI slot attributes and hotplug attributes.  In this patch, the PCI
      hotplug core remains the only user of this infrastructure, and thus,
      /sys/bus/pci/slots/ will still only become populated when a hotplug
      driver is loaded.
      
      A later patch in this series will add a second user of this new
      infrastructure and demonstrate splitting the task of exposing pci_slot
      attributes from hotplug_slot attributes.
      
        - Make pci_slot the primary sysfs entity. hotplug_slot becomes a
          subsidiary structure.
          o pci_create_slot() creates and registers a slot with the PCI core
          o pci_slot_add_hotplug() gives it hotplug capability
      
        - Change the prototype of pci_hp_register() to take the bus and
          slot number (on parent bus) as parameters.
      
        - Remove all the ->get_address methods since this functionality is
          now handled by pci_slot directly.
      
      [achiang@hp.com: rpaphp-correctly-pci_hp_register-for-empty-pci-slots]
      Tested-by: default avatarBadari Pulavarty <pbadari@us.ibm.com>
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: make headers_check happy]
      [akpm@linux-foundation.org: nuther build fix]
      [akpm@linux-foundation.org: fix typo in #include]
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarMatthew Wilcox <matthew@wil.cx>
      Cc: Greg KH <greg@kroah.com>
      Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Acked-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      f46753c5
    • Kenji Kaneshige's avatar
      shpchp: check firmware before taking control · ac9c052d
      Kenji Kaneshige authored
      Fix the following problems of shpchp driver about getting hotplug
      control from firmware.
      
        - The shpchp driver must not control the hotplug controller if it
          fails to get control from the firmware. But current shpchp
          controls the hotplug controller regardless the result, because it
          doesn't check the return value of get_hp_hw_control_from_firmware().
      
        - Current shpchp driver doesn't support _OSC.
      
      The pciehp driver already have the code for evaluating _OSC and OSHP
      and shpchp and pciehp can share it. So this patch move that code from
      pciehp to acpi_pcihp.c.
      Signed-off-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      ac9c052d
  25. 25 Jan, 2008 1 commit
  26. 03 May, 2007 1 commit
  27. 18 Oct, 2006 2 commits