1. 12 6月, 2014 1 次提交
  2. 07 2月, 2014 2 次提交
    • R
      ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify() · 1a699476
      Rafael J. Wysocki 提交于
      Since acpi_bus_notify() is executed on all notifications for all
      devices anyway, make it execute acpi_device_hotplug() for all
      hotplug events instead of installing notify handlers pointing to
      the same function for all hotplug devices.
      
      This change reduces both the size and complexity of ACPI-based device
      hotplug code.  Moreover, since acpi_device_hotplug() only does
      significant things for devices that have either an ACPI scan handler,
      or a hotplug context with .eject() defined, and those devices
      had notify handlers pointing to acpi_hotplug_notify_cb() installed
      before anyway, this modification shouldn't change functionality.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1a699476
    • R
      ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplug · 3c2cc7ff
      Rafael J. Wysocki 提交于
      The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
      hotplug context objects directly to ACPI namespace nodes representing
      hotplug devices.  However, after recent changes causing struct
      acpi_device to be created for every namespace node representing a
      device (regardless of its status), that is not necessary any more.
      Moreover, it's vulnerable to the theoretical issue that the ACPI
      handle passed in the context between handle_hotplug_event() and
      hotplug_event_work() may become invalid in the meantime (as a
      result of a concurrent table unload).
      
      In principle, this issue might be addressed by adding a non-empty
      release handler for ACPIPHP hotplug context objects analogous to
      acpi_scan_drop_device(), but that would duplicate the code in that
      function and in acpi_device_del_work_fn().  For this reason, it's
      better to modify ACPIPHP to attach its device hotplug contexts to
      struct device objects representing hotplug devices and make it
      use acpi_hotplug_notify_cb() as its notify handler.  At the same
      time, acpi_device_hotplug() can be modified to dispatch the new
      .hp.event() callback pointing to acpiphp_hotplug_event() from ACPI
      device objects associated with PCI devices or use the generic
      ACPI device hotplug code for device objects with matching scan
      handlers.
      
      This allows the existing code duplication between ACPIPHP and the
      ACPI core to be reduced too and makes further ACPI-based device
      hotplug consolidation possible.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3c2cc7ff
  3. 06 2月, 2014 2 次提交
    • R
      ACPI / hotplug / PCI: Drop crit_sect locking · 661b4064
      Rafael J. Wysocki 提交于
      After recent PCI core changes related to the rescan/remove locking,
      the code sections under crit_sect mutexes from ACPIPHP slot objects
      are always executed under the general PCI rescan/remove lock.
      For this reason, the crit_sect mutexes are simply redundant, so drop
      them.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      661b4064
    • R
      ACPI / hotplug / PCI: Store acpi_device pointer in acpiphp_context · bbcbfc0e
      Rafael J. Wysocki 提交于
      After recent modifications of the ACPI core making it create a struct
      acpi_device object for every namespace node representing a device
      regardless of the current status of that device the ACPIPHP code
      can store a struct acpi_device pointer instead of an ACPI handle
      in struct acpiphp_context.  This immediately makes it possible to
      avoid making potentially costly calls to acpi_bus_get_device() in
      two places and allows some more simplifications to be made going
      forward.
      
      The reason why that is correct is because ACPIPHP only installs
      hotify handlers for namespace nodes that exist when
      acpiphp_enumerate_slots() is called for their parent bridge.
      That only happens if the parent bridge has an ACPI companion
      associated with it, which means that the ACPI namespace scope
      in question has been scanned already at that point.  That, in
      turn, means that struct acpi_device objects have been created
      for all namespace nodes in that scope and pointers to those
      objects can be stored directly instead of their ACPI handles.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      bbcbfc0e
  4. 15 1月, 2014 1 次提交
  5. 20 11月, 2013 1 次提交
  6. 26 9月, 2013 1 次提交
    • L
      PCI: acpiphp: Convert to dynamic debug · bd950799
      Lan Tianyu 提交于
      This patch is to use pr_debug/info/warn/err to replace acpiphp debug
      functions and remove module's debug param.
      
      User interface change: before this patch, boot with the "acpiphp.debug"
      kernel parameter to turn on debug.  After this patch, set
      CONFIG_DYNAMIC_DEBUG=y and boot with "acpiphp.dyndebug=+p" instead.
      See Documentation/dynamic-debug-howto.txt.
      
      [bhelgaas: changelog]
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      bd950799
  7. 23 7月, 2013 13 次提交
  8. 15 7月, 2013 1 次提交
    • R
      ACPI / dock / PCI: Drop ACPI dock notifier chain · f09ce741
      Rafael J. Wysocki 提交于
      The only user of the ACPI dock notifier chain is the ACPI-based PCI
      hotplug (acpiphp) driver that uses it to carry out post-dock fixups
      needed by some systems with broken _DCK.  However, it is not
      necessary to use a separate notifier chain for that, as it can be
      simply replaced with a new callback in struct acpi_dock_ops.
      
      For this reason, add a new .fixup() callback to struct acpi_dock_ops
      and make hotplug_dock_devices() execute it for all dock devices with
      hotplug operations registered.  Accordingly, make acpiphp point that
      callback to the function carrying out the post-dock fixups and
      do not register a separate dock notifier for each device
      registering dock operations.  Finally, drop the ACPI dock notifier
      chain that has no more users.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f09ce741
  9. 18 4月, 2013 1 次提交
  10. 17 4月, 2013 2 次提交
  11. 13 4月, 2013 3 次提交
  12. 03 2月, 2013 1 次提交
    • J
      PCI: acpiphp: Remove dead code for PCI host bridge hotplug · be6d2867
      Jiang Liu 提交于
      Commit 668192b6 "PCI: acpiphp: Move host bridge hotplug
      to pci_root.c" has moved PCI host bridge hotplug logic from acpiphp
      to pci_root, but there is still PCI host bridge hotplug related
      dead code left in acpiphp. So remove those dead code.
      
      Now companion ACPI devices are always created before corresponding
      PCI devices. And the ACPI event handle_hotplug_event_bridge() will be
      installed only if it has associated PCI device. So remove dead code to
      handle bridge hot-adding in function handle_hotplug_event_bridge().
      Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      be6d2867
  13. 26 1月, 2013 1 次提交
  14. 11 7月, 2012 2 次提交
  15. 11 1月, 2011 1 次提交
  16. 05 11月, 2009 1 次提交
    • B
      PCI hotplug: move IOAPIC support from acpiphp to ioapic driver · 204d49a5
      Bjorn Helgaas 提交于
      This patch moves PCI I/O APIC support from acpiphp to a separate driver.
      
      Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and
      removal of PCI adapters.  But in addition, acpiphp handles some ACPI
      hotplug, such as the addition of new host bridges, and the I/O APIC
      support was tangled up with that.
      
      I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs
      usually appear as a function on a PCI host bridge, and we'll enumerate the
      APIC before any of the devices behind the bridge that use it.
      
      As far as I know, nobody actually uses I/O APIC hotplug.  It depends on
      acpi_register_ioapic(), which is only implemented for ia64, and I don't
      think any vendors have supported I/O chassis hotplug yet.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      CC: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
      CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      204d49a5
  17. 15 9月, 2009 1 次提交
  18. 27 5月, 2009 1 次提交
    • A
      PCI Hotplug: acpiphp: don't store a pci_dev in acpiphp_func · 9d911d79
      Alex Chiang 提交于
      An oops can occur if a user attempts to use both PCI logical
      hotplug and the ACPI physical hotplug driver (acpiphp) in this
      sequence, where $slot/address == $device.
      
      In other words, if acpiphp has claimed a PCI device, and that
      device is logically removed, then acpiphp may oops when it
      attempts to access it again.
      
      	# echo 1 > /sys/bus/pci/devices/$device/remove
      	# echo 0 > /sys/bus/pci/slots/$slot/power
      
      Unable to handle kernel NULL pointer dereference (address 0000000000000000)
      Call Trace:
       [<a000000100016390>] show_stack+0x50/0xa0
       [<a000000100016c60>] show_regs+0x820/0x860
       [<a00000010003b390>] die+0x190/0x2a0
       [<a000000100066a40>] ia64_do_page_fault+0x8e0/0xa40
       [<a00000010000c7a0>] ia64_native_leave_kernel+0x0/0x270
       [<a0000001003b2660>] pci_remove_bus_device+0x120/0x260
       [<a0000002060549f0>] acpiphp_disable_slot+0x410/0x540 [acpiphp]
       [<a0000002060505c0>] disable_slot+0xc0/0x120 [acpiphp]
       [<a0000002040d21c0>] power_write_file+0x1e0/0x2a0 [pci_hotplug]
       [<a0000001003bb820>] pci_slot_attr_store+0x60/0xa0
       [<a000000100240f70>] sysfs_write_file+0x230/0x2c0
       [<a000000100195750>] vfs_write+0x190/0x2e0
       [<a0000001001961a0>] sys_write+0x80/0x100
       [<a00000010000c600>] ia64_ret_from_syscall+0x0/0x20
       [<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
      
      The root cause of this oops is that the logical remove ("echo 1 >
      /sys/bus/pci/devices/$device/remove") destroyed the pci_dev. The
      pci_dev struct itself wasn't deallocated because acpiphp kept a
      reference, but some of its fields became invalid.
      
      acpiphp doesn't have any real reason to keep a pointer to a
      pci_dev around. It can always derive it using pci_get_slot().
      
      If a logical remove destroys the pci_dev, acpiphp won't find it
      and is thus prevented from causing mischief.
      Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Tested-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Reported-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9d911d79
  19. 08 1月, 2009 1 次提交
  20. 17 12月, 2008 1 次提交
  21. 23 10月, 2008 1 次提交
  22. 22 7月, 2008 1 次提交