1. 30 5月, 2014 2 次提交
    • Z
      ACPI / PNP: use device ID list for PNPACPI device enumeration · eec15edb
      Zhang Rui 提交于
      ACPI can be used to enumerate PNP devices, but the code does not
      handle this in the right way currently.  Namely, if an ACPI device
      object
       1. Has a _CRS method,
       2. Has an identification of
          "three capital characters followed by four hex digits",
       3. Is not in the excluded IDs list,
      it will be enumerated to PNP bus (that is, a PNP device object will
      be create for it).  This means that, actually, the PNP bus type is
      used as the default bus type for enumerating _HID devices in ACPI.
      
      However, more and more _HID devices need to be enumerated to the
      platform bus instead (that is, platform device objects need to be
      created for them).  As a result, the device ID list in acpi_platform.c
      is used to enforce creating platform device objects rather than PNP
      device objects for matching devices.  That list has been continuously
      growing recently, unfortunately, and it is pretty much guaranteed to
      grow even more in the future.
      
      To address that problem it is better to enumerate _HID devices
      as platform devices by default.  To this end, change the way of
      enumerating PNP devices by adding a PNP ACPI scan handler that
      will use a device ID list to create PNP devices for the ACPI
      device objects whose device IDs are present in that list.
      
      The initial device ID list in the PNP ACPI scan handler contains
      all of the pnp_device_id strings from all the existing PNP drivers,
      so this change should be transparent to the PNP core and all of the
      PNP drivers.  Still, in the future it should be possible to reduce
      its size by converting PNP drivers that need not be PNP for any
      technical reasons into platform drivers.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      [rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      eec15edb
    • R
      ACPI / scan: .match() callback for ACPI scan handlers · aca0a4eb
      Rafael J. Wysocki 提交于
      Introduce a .match() callback for ACPI scan handlers to allow them to
      use more elaborate matching algorithms if necessary.  That is needed
      for the upcoming PNP scan handler in particular.
      
      This change is based on a Zhang Rui's prototype.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      aca0a4eb
  2. 20 5月, 2014 1 次提交
  3. 05 3月, 2014 1 次提交
  4. 22 2月, 2014 2 次提交
  5. 21 2月, 2014 2 次提交
  6. 16 2月, 2014 2 次提交
    • R
      ACPI / dock: Pass ACPI device pointer to acpi_device_is_battery() · b43109fa
      Rafael J. Wysocki 提交于
      Since we already know what the device's PNP IDs are when
      acpi_device_is_battery() is called, it is not necessary to run
      acpi_get_object_info() for the device in that function.  Instead, if
      acpi_device_is_battery() is passed a pointer to a struct acpi_device
      object, it can use the list of PNP IDs from that object, so make that
      happen and modify the function's header accordingly
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b43109fa
    • R
      ACPI / dock: Dispatch dock notifications from the global notify handler · 1e2380cd
      Rafael J. Wysocki 提交于
      The ACPI dock station code carries out an extra namespace scan
      before the main one in order to find and register all of the dock
      device objects.  Then, it registers a notify handler for each of
      them for handling dock events.
      
      However, dock device objects need not be scanned for upfront.  They
      very well can be enumerated and registered during the first phase
      of the main namespace scan, before attaching scan handlers and ACPI
      drivers to ACPI device objects.  Then, the dependent devices can be
      added to the in the second phase.  That makes it possible to drop
      the extra namespace scan, so do it.
      
      Moreover, it is not necessary to register notify handlers for all
      of the dock stations' namespace nodes, becuase notifications may
      be dispatched from the global notify handler for them.  Do that and
      drop two functions used for dock notify handling, acpi_dock_deferred_cb()
      and dock_notify_handler(), that aren't necessary any more.
      
      Finally, some dock station objects have _HID objects matching the
      ACPI container scan handler which causes it to claim those objects
      and try to handle their hotplug, but that is not a good idea,
      because those objects have their own special hotplug handling anyway.
      For this reason, the hotplug_notify flag should not be set for ACPI
      device objects representing dock stations and the container scan
      handler should be made ignore those objects, so make that happen.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1e2380cd
  7. 11 2月, 2014 1 次提交
    • R
      ACPI / scan: Add bind/unbind callbacks to struct acpi_scan_handler · 9cb32acf
      Rafael J. Wysocki 提交于
      In some cases it may be necessary to perform certain setup/cleanup
      operations on a device object representing a physical device after
      it has been associated with an ACPI companion by acpi_bind_one() or
      before disassociating it from that companion by acpi_unbind_one(),
      respectively.  If there is a struct acpi_bus_type object for the
      given device's bus type, the .setup()/.cleanup() callbacks from there
      are executed for these purposes.  However, an analogous mechanism will
      be necessary for devices whose bus types don't have corresponding
      struct acpi_bus_type objects and that have specific ACPI scan handlers.
      
      For those devices, add new .bind() and .unbind() callbacks to struct
      acpi_scan_handler that will be executed by acpi_platform_notify()
      right after the given device has been associated with an ACPI
      comapnion and by acpi_platform_notify_remove() right before calling
      acpi_unbind_one() for that device, respectively.
      
      To make that work for scan handlers registering new devices in their
      .attach() callbacks, modify acpi_scan_attach_handler() to set the
      ACPI device object's handler field before calling .attach() from the
      scan handler at hand.
      
      This changeset includes a fix from Mika Westerberg.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9cb32acf
  8. 07 2月, 2014 4 次提交
    • 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: Simplify acpi_install_hotplug_notify_handler() · 5e6f236c
      Rafael J. Wysocki 提交于
      Since acpi_hotplug_notify_cb() does not use its data argument any
      more, the second argument of acpi_install_hotplug_notify_handler()
      can be dropped, so do that and update its callers accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5e6f236c
    • R
      ACPI / hotplug / PCI: Rework the handling of eject requests · dd2151be
      Rafael J. Wysocki 提交于
      To avoid the need to install a hotplug notify handler for each ACPI
      namespace node representing a device and having a matching scan
      handler, move the check whether or not the ejection of the given
      device is enabled through its scan handler from acpi_hotplug_notify_cb()
      to acpi_generic_hotplug_event().  Also, move the execution of
      ACPI_OST_SC_EJECT_IN_PROGRESS _OST to acpi_generic_hotplug_event(),
      because in acpi_hotplug_notify_cb() or in acpi_eject_store() we really
      don't know whether or not the eject is going to be in progress (for
      example, acpi_hotplug_execute() may still fail without queuing up the
      work item).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      dd2151be
    • 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
  9. 06 2月, 2014 2 次提交
    • R
      ACPI / hotplug / PCI: Define hotplug context lock in the core · e525506f
      Rafael J. Wysocki 提交于
      Subsequent changes will require the ACPI core to acquire the lock
      protecting the ACPIPHP hotplug contexts, so move the definition of
      the lock to the core and change its name to be more generic.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      e525506f
    • R
      ACPI / hotplug: Fix potential race in acpi_bus_notify() · 78ea4639
      Rafael J. Wysocki 提交于
      There is a slight possibility for the ACPI device object pointed to
      by adev in acpi_hotplug_notify_cb() to become invalid between the
      acpi_bus_get_device() that it comes from and the subsequent dereference
      of that pointer under get_device().  Namely, if acpi_scan_drop_device()
      runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn()
      queued up by it may delete the device object in question right after
      a successful execution of acpi_bus_get_device() in acpi_bus_notify().
      
      An analogous problem is present in acpi_bus_notify() where the device
      pointer coming from acpi_bus_get_device() may become invalid before
      it subsequent dereference in the "if" block.
      
      To prevent that from happening, introduce a new function,
      acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device()
      except that it will grab a reference to the ACPI device object returned
      by it and it will do that under the ACPICA's namespace mutex.  Then,
      make both acpi_hotplug_notify_cb() and acpi_bus_notify() use
      acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to
      ensure that the pointers used by them will not become stale at one
      point.
      
      In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper
      around put_device() to be used along with acpi_bus_get_acpi_device()
      and make the (new) users of the latter use acpi_bus_put_acpi_device()
      too.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      78ea4639
  10. 05 2月, 2014 1 次提交
    • T
      ACPI / hotplug: Fix panic on eject to ejected device · 8fcfb99c
      Toshi Kani 提交于
      When an eject request is sent to an ejected ACPI device, the following
      panic occurs:
      
       ACPI: \_SB_.SCK3.CPU3: ACPI_NOTIFY_EJECT_REQUEST event
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
       IP: [<ffffffff813a7cfe>] acpi_device_hotplug+0x10b/0x33b
      	:
       Call Trace:
       [<ffffffff813a24da>] acpi_hotplug_work_fn+0x1c/0x27
       [<ffffffff8109cbe5>] process_one_work+0x175/0x430
       [<ffffffff8109d7db>] worker_thread+0x11b/0x3a0
      
      This is becase device->handler is NULL in acpi_device_hotplug().
      This case was used to fail in acpi_hotplug_notify_cb() as the target
      had no acpi_deivce.  However, acpi_device now exists after ejection.
      
      Added a check to verify if acpi_device->handler is valid for an
      eject request in acpi_hotplug_notify_cb().  Note that handler passed
      from an argument is still valid while acpi_device->handler is NULL.
      
      Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8fcfb99c
  11. 29 1月, 2014 1 次提交
  12. 17 1月, 2014 2 次提交
    • Z
      ACPI: add module autoloading support for ACPI enumerated devices · 6eb2451f
      Zhang Rui 提交于
      An ACPI enumerated device may have its compatible id strings.
      
      To support the compatible ACPI ids (acpi_device->pnp.ids),
      we introduced acpi_driver_match_device() to match
      the driver->acpi_match_table and acpi_device->pnp.ids.
      
      For those drivers, MODULE_DEVICE_TABLE(acpi, xxx) is used to
      exports the driver module alias in the format of
      "acpi:device_compatible_ids".
      But in the mean time, the current code does not export the
      ACPI compatible strings as part of the module_alias for the
      ACPI enumerated devices, which will break the module autoloading.
      
      Take the following piece of code for example,
      static const struct acpi_device_id xxx_acpi_match[] = {
              { "INTABCD", 0 },
              { }
      };
      MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
      
      If this piece of code is used in a platform driver for
      an ACPI enumerated platform device, the platform driver module_alias
      is "acpi:INTABCD", but the uevent attribute of its platform device node
      is "platform:INTABCD:00" (PREFIX:platform_device->name).
      If this piece of code is used in an i2c driver for an ACPI enumerated
      i2c device, the i2c driver module_alias is "acpi:INTABCD", but
      the uevent of its i2c device node is "i2c:INTABCD:00" (PREFIX:i2c_client->name).
      If this piece of code is used in an spi driver for an ACPI enumerated
      spi device, the spi driver module_alias is "acpi:INTABCD", but
      the uevent of its spi device node is "spi:INTABCD" (PREFIX:spi_device->modalias).
      
      The reason why the module autoloading is not broken for now is that
      the uevent file of the ACPI device node is "acpi:INTABCD".
      Thus it is the ACPI device node creation that loads the platform/i2c/spi driver.
      
      So this is a problem that will affect us the day when the ACPI bus
      is removed from device model.
      
      This patch introduces two new APIs,
      one for exporting ACPI ids in uevent MODALIAS field,
      and another for exporting ACPI ids in device' modalias sysfs attribute.
      
      For any bus that supports ACPI enumerated devices, it needs to invoke
      these two functions for their uevent and modalias attribute.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6eb2451f
    • Z
      ACPI: fix create_modalias() return value handling · 3d8e0090
      Zhang Rui 提交于
      Currently, create_modalias() handles the output truncated case in
      an improper way (return -EINVAL).
      Plus, acpi_device_uevent() and acpi_device_modalias_show() do
      improper check for the create_modalias() return value as well.
      
      This patch fixes create_modalias() to
      return -EINVAL if there is an output error,
      return -ENOMEM if the output is truncated,
      and also fixes both acpi_device_uevent() and acpi_device_modalias_show()
      to do proper return value check.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3d8e0090
  13. 11 1月, 2014 1 次提交
  14. 29 12月, 2013 2 次提交
    • R
      ACPI / hotplug / driver core: Handle containers in a special way · caa73ea1
      Rafael J. Wysocki 提交于
      ACPI container devices require special hotplug handling, at least
      on some systems, since generally user space needs to carry out
      system-specific cleanup before it makes sense to offline devices in
      the container.  However, the current ACPI hotplug code for containers
      first attempts to offline devices in the container and only then it
      notifies user space of the container offline.
      
      Moreover, after commit 202317a5 (ACPI / scan: Add acpi_device
      objects for all device nodes in the namespace), ACPI device objects
      representing containers are present as long as the ACPI namespace
      nodes corresponding to them are present, which may be forever, even
      if the container devices are physically detached from the system (the
      return values of the corresponding _STA methods change in those
      cases, but generally the namespace nodes themselves are still there).
      Thus it is useful to introduce entities representing containers that
      will go away during container hot-unplug.
      
      The goal of this change is to address both the above issues.
      
      The idea is to create a "companion" container system device for each
      of the ACPI container device objects during the initial namespace
      scan or on a hotplug event making the container present.  That system
      device will be unregistered on container removal.  A new bus type
      for container devices is added for this purpose, because device
      offline and online operations need to be defined for them.  The
      online operation is a trivial function that is always successful
      and the offline uses a callback pointed to by the container device's
      offline member.
      
      For ACPI containers that callback simply walks the list of ACPI
      device objects right below the container object (its children) and
      checks if all of their physical companion devices are offline.  If
      that's not the case, it returns -EBUSY and the container system
      devivce cannot be put offline.  Consequently, to put the container
      system device offline, it is necessary to put all of the physical
      devices depending on its ACPI companion object offline beforehand.
      
      Container system devices created for ACPI container objects are
      initially online.  They are created by the container ACPI scan
      handler whose hotplug.demand_offline flag is set.  That causes
      acpi_scan_hot_remove() to check if the companion container system
      device is offline before attempting to remove an ACPI container or
      any devices below it.  If the check fails, a KOBJ_CHANGE uevent is
      emitted for the container system device in question and user space
      is expected to offline all devices below the container and the
      container itself in response to it.  Then, user space can finalize
      the removal of the container with the help of its ACPI device
      object's eject attribute in sysfs.
      Tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      caa73ea1
    • R
      ACPI / hotplug: Add demand_offline hotplug profile flag · d22ddcbc
      Rafael J. Wysocki 提交于
      Add a new ACPI hotplug profile flag, demand_offline, such that if
      set for the given ACPI device object's scan handler, it will cause
      acpi_scan_hot_remove() to check if that device object's physical
      companions are offline upfront and fail the hot removal if that
      is not the case.
      
      That flag will be useful to overcome a problem with containers on
      some system where they can only be hot-removed after some cleanup
      operations carried out by user space, which needs to be notified
      of the container hot-removal before the kernel attempts to offline
      devices in the container.  In those cases the current implementation
      of acpi_scan_hot_remove() is not sufficient, because it first tries
      to offline the devices in the container and only if that is
      suffcessful it tries to offline the container itself.  As a result,
      the container hot-removal notification is not delivered to user space
      at the right time.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d22ddcbc
  15. 07 12月, 2013 1 次提交
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng 提交于
      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: NLv 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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  16. 25 11月, 2013 1 次提交
  17. 23 11月, 2013 8 次提交
    • R
      ACPI: Introduce acpi_set_device_status() · 25db115b
      Rafael J. Wysocki 提交于
      Introduce a static inline function for setting the status field
      of struct acpi_device on the basis of a supplied u32 number,
      acpi_set_device_status(), and use it instead of the horrible
      horrible STRUCT_TO_INT() macro wherever applicable.  Having done
      that, drop STRUCT_TO_INT() (and pretend that it has never existed).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      25db115b
    • R
      ACPI / hotplug: Rework generic code to handle suprise removals · 443fc820
      Rafael J. Wysocki 提交于
      The generic ACPI hotplug code used for several types of device
      doesn't handle surprise removals, mostly because those devices
      currently cannot be removed by surprise in the majority of systems.
      However, surprise removals should be handled by that code as well
      as surprise additions of devices, so make it do that.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      443fc820
    • R
      ACPI / hotplug: Move container-specific code out of the core · 46394fd0
      Rafael J. Wysocki 提交于
      Move container-specific uevents from the core hotplug code to the
      container scan handler's .attach() and .detach() callbacks.
      
      This way the core will not have to special-case containers and
      the uevents will be guaranteed to happen every time a container
      is either scanned or trimmed as appropriate.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      46394fd0
    • R
      ACPI / hotplug: Make ACPI PCI root hotplug use common hotplug code · 3338db00
      Rafael J. Wysocki 提交于
      Rework the common ACPI device hotplug code so that it is suitable
      for PCI host bridge hotplug and switch the PCI host bridge scan
      handler to using the common hotplug code.
      
      This allows quite a few lines of code that are not necessary any more
      to be dropped from the PCI host bridge scan handler and removes
      arbitrary differences in behavior between PCI host bridge hotplug
      and ACPI-based hotplug of other components, like CPUs and memory.
      
      Also acpi_device_hotplug() can be static now.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      3338db00
    • R
      ACPI / hotplug: Introduce common hotplug function acpi_device_hotplug() · c27b2c33
      Rafael J. Wysocki 提交于
      Modify the common ACPI device hotplug code to always queue up the
      same function, acpi_device_hotplug(), using acpi_hotplug_execute()
      and make the PCI host bridge hotplug code use that function too for
      device hot removal.
      
      This allows some code duplication to be reduced and a race condition
      where the relevant ACPI handle may become invalid between the
      notification handler and the function queued up by it via
      acpi_hotplug_execute() to be avoided.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      c27b2c33
    • R
      ACPI / hotplug: Do not fail bus and device checks for disabled hotplug · 1ceaba05
      Rafael J. Wysocki 提交于
      If the scan handler for the given device has hotplug.enabled
      unset, it doesn't really make sense to fail bus check and device
      check notifications.
      
      First, bus check may not have anything to do with the device it is
      signaled for, but it may concern another device on the bus below
      this one.  For this reason, bus check notifications should not be
      failed if hotplug is disabled for the target device.
      
      Second, device check notifications are signaled only after a device
      has already appeared (or disappeared), so failing it can only prevent
      scan handlers and drivers from attaching to that (already existing)
      device, which is not very useful.
      
      Consequently, if device hotplug is disabled through the device's
      scan handler, fail eject request notifications only.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      1ceaba05
    • R
      ACPI / scan: Add acpi_device objects for all device nodes in the namespace · 202317a5
      Rafael J. Wysocki 提交于
      Modify the ACPI namespace scanning code to register a struct
      acpi_device object for every namespace node representing a device,
      processor and so on, even if the device represented by that namespace
      node is reported to be not present and not functional by _STA.
      
      There are multiple reasons to do that.  First of all, it avoids
      quite a lot of overhead when struct acpi_device objects are
      deleted every time acpi_bus_trim() is run and then added again
      by a subsequent acpi_bus_scan() for the same scope, although the
      namespace objects they correspond to stay in memory all the time
      (which always is the case on a vast majority of systems).
      
      Second, it will allow user space to see that there are namespace
      nodes representing devices that are not present at the moment and may
      be added to the system.  It will also allow user space to evaluate
      _SUN for those nodes to check what physical slots the "missing"
      devices may be put into and it will make sense to add a sysfs
      attribute for _STA evaluation after this change (that will be
      useful for thermal management on some systems).
      
      Next, it will help to consolidate the ACPI hotplug handling among
      subsystems by making it possible to store hotplug-related information
      in struct acpi_device objects in a standard common way.
      
      Finally, it will help to avoid a race condition related to the
      deletion of ACPI namespace nodes.  Namely, namespace nodes may be
      deleted as a result of a table unload triggered by _EJ0 or _DCK.
      If a hotplug notification for one of those nodes is triggered
      right before the deletion and it executes a hotplug callback
      via acpi_hotplug_execute(), the ACPI handle passed to that
      callback may be stale when the callback actually runs.  One way
      to work around that is to always pass struct acpi_device pointers
      to hotplug callbacks after doing a get_device() on the objects in
      question which eliminates the use-after-free possibility (the ACPI
      handles in those objects are invalidated by acpi_scan_drop_device(),
      so they will trigger ACPICA errors on attempts to use them).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      202317a5
    • R
      ACPI / scan: Define non-empty device removal handler · d783156e
      Rafael J. Wysocki 提交于
      If an ACPI namespace node is removed (usually, as a result of a
      table unload), and there is a data object attached to that node,
      acpi_ns_delete_node() executes the removal handler submitted to
      acpi_attach_data() for that object.  That handler is currently empty
      for struct acpi_device objects, so it is necessary to detach those
      objects from the corresponding ACPI namespace nodes in advance every
      time a table unload may happen.  That is cumbersome and inefficient
      and leads to some design constraints that turn out to be quite
      inconvenient (in particular, struct acpi_device objects cannot be
      registered for namespace nodes representing devices that are not
      reported as present or functional by _STA).
      
      For this reason, introduce a non-empty removal handler for ACPI
      device objects that will unregister them when their ACPI namespace
      nodes go away.
      
      This code modification alone should not change functionality except
      for the ordering of the ACPI hotplug workqueue which should not
      matter (without subsequent code changes).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      d783156e
  18. 20 11月, 2013 1 次提交
    • T
      ACPI / hotplug: Fix conflicted PCI bridge notify handlers · ca499fc8
      Toshi Kani 提交于
      The PCI host bridge scan handler installs its own notify handler,
      handle_hotplug_event_root(), by itself.  Nevertheless, the ACPI
      hotplug framework also installs the common notify handler,
      acpi_hotplug_notify_cb(), for PCI root bridges.  This causes
      acpi_hotplug_notify_cb() to call _OST method with unsupported
      error as hotplug.enabled is not set.
      
      To address this issue, introduce hotplug.ignore flag, which
      indicates that the scan handler installs its own notify handler by
      itself.  The ACPI hotplug framework does not install the common
      notify handler when this flag is set.
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      [rjw: Changed the name of the new flag]
      Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ca499fc8
  19. 19 11月, 2013 3 次提交
  20. 08 11月, 2013 1 次提交
    • R
      ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines · 7b98118a
      Rafael J. Wysocki 提交于
      There are two different interfaces for queuing up work items on the
      ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
      bridge hotplug code and acpi_os_hotplug_execute() used by the common
      ACPI hotplug code and docking stations.  They both are somewhat
      cumbersome to use and work slightly differently.
      
      The users of alloc_acpi_hp_work() have to submit a work function that
      will extract the necessary data items from a struct acpi_hp_work
      object allocated by alloc_acpi_hp_work() and then will free that
      object, while it would be more straightforward to simply use a work
      function with one more argument and let the interface take care of
      the execution details.
      
      The users of acpi_os_hotplug_execute() also have to deal with the
      fact that it takes only one argument in addition to the work function
      pointer, although acpi_os_execute_deferred() actually takes care of
      the allocation and freeing of memory, so it would have been able to
      pass more arguments to the work function if it hadn't been
      constrained by the connection with acpi_os_execute().
      
      Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
      allocations, which is correct, because hotplug work items are
      always queued up from process context, acpi_os_hotplug_execute()
      uses GFP_ATOMIC, as that is needed by acpi_os_execute().  Also,
      acpi_os_execute_deferred() queued up by it waits for the ACPI event
      workqueues to flush before executing the work function, whereas
      alloc_acpi_hp_work() can't do anything similar.  That leads to
      somewhat arbitrary differences in behavior between various ACPI
      hotplug code paths and has to be straightened up.
      
      For this reason, replace both alloc_acpi_hp_work() and
      acpi_os_hotplug_execute() with a single interface,
      acpi_hotplug_execute(), combining their behavior and being more
      friendly to its users than any of the two.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      7b98118a
  21. 07 11月, 2013 1 次提交
    • R
      ACPI / hotplug: Do not execute "insert in progress" _OST · 176a88d7
      Rafael J. Wysocki 提交于
      According to the ACPI spec (5.0, Section 6.3.5), the "Device
      insertion in progress (pending)" (0x80) _OST status code is
      reserved for the "Insertion Processing" (0x200) source event
      which is "a result of an OSPM action".  Specifically, it is not
      a notification, so that status code should not be used during
      notification processing, which unfortunately is done by
      acpi_scan_bus_device_check().
      
      For this reason, drop the ACPI_OST_SC_INSERT_IN_PROGRESS _OST
      status evaluation from there (it was a mistake to put it in there
      in the first place).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: All applicable <stable@vger.kernel.org>
      176a88d7