1. 22 9月, 2014 1 次提交
  2. 21 9月, 2014 1 次提交
    • R
      ACPI / hotplug: Generate online uevents for ACPI containers · 8ab17fc9
      Rafael J. Wysocki 提交于
      Commit 46394fd0 (ACPI / hotplug: Move container-specific code out of
      the core) removed the generation of "online" uevents for containers,
      because "add" uevents are now generated for them automatically when
      container system devices are registered.  However, there are user
      space tools that need to be notified when the container and all of
      its children have been enumerated, which doesn't happen any more.
      
      For this reason, add a mechanism allowing "online" uevents to be
      generated for ACPI containers after enumerating the container along
      with all of its children.
      
      Fixes: 46394fd0 (ACPI / hotplug: Move container-specific code out of the core)
      Reported-and-tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8ab17fc9
  3. 11 9月, 2014 1 次提交
    • Z
      ACPI: introduce ACPI int340x thermal scan handler · 3230bbfc
      Zhang Rui 提交于
      Newer laptops and tablets that use ACPI may have thermal sensors and
      other devices with thermal control capabilities outside the core CPU/SOC,
      for thermal safety reasons.
      They are exposed for the OS to use via
      1) INT3400 ACPI device object as the master.
      2) INT3401 ~ INT340B ACPI device objects as the slaves.
      
      This patch introduces a scan handler to enumerate the INT3400
      ACPI device object to platform bus, and prevent its slaves
      from being enumerated before the controller driver being probed.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      3230bbfc
  4. 04 9月, 2014 1 次提交
  5. 26 8月, 2014 2 次提交
  6. 08 8月, 2014 1 次提交
    • T
      ACPI / hotplug: Check scan handlers in acpi_scan_hot_remove() · dee15926
      Tang Chen 提交于
      When ACPI_HOTPLUG_MEMORY is not configured, memory_device_handler.attach
      is not set.  In acpi_scan_attach_handler(), the acpi_device->handler will
      not be initialized.
      
      In acpi_scan_hot_remove(), it doesn't check if acpi_device->handler is NULL.
      If we do memory hot-remove without ACPI_HOTPLUG_MEMORY configured, the kernel
      will panic.
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
       IP: [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4
       PGD 0
       Oops: 0000 [#1] SMP
       Modules linked in: sd_mod(E) sr_mod(E) cdrom(E) crc_t10dif(E) crct10dif_common(E) ata_piix(E) libata(E)
       CPU: 0 PID: 41 Comm: kworker/u2:1 Tainted: G            E 3.16.0-rc7--3.16-rc7-tangchen+ #20
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
       Workqueue: kacpi_hotplug acpi_hotplug_work_fn
       task: ffff8800182436c0 ti: ffff880018254000 task.ti: ffff880018254000
       RIP: 0010:[<ffffffff813e318f>]  [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4
       RSP: 0000:ffff880018257da8  EFLAGS: 00000246
       RAX: 0000000000000000 RBX: ffff88001cd8d800 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff88001e40e6f8 RDI: 0000000000000246
       RBP: ffff880018257df0 R08: 0000000000000096 R09: 00000000000011a0
       R10: 63735f6970636120 R11: 725f746f685f6e61 R12: 0000000000000003
       R13: ffff88001cc1c400 R14: ffff88001e062028 R15: 0000000000000040
       FS:  0000000000000000(0000) GS:ffff88001e400000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000088 CR3: 000000001a9a2000 CR4: 00000000000006f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
       Stack:
        00000000523cab58 ffff88001cd8d9f8 ffff88001852d480 00000000523cab58
        ffff88001852d480 ffff880018221e40 ffff88001cc1c400 ffff88001cce2d00
        0000000000000040 ffff880018257e08 ffffffff813dc31d ffff88001852d480
       Call Trace:
        [<ffffffff813dc31d>] acpi_hotplug_work_fn+0x1e/0x29
        [<ffffffff8108eefb>] process_one_work+0x17b/0x460
        [<ffffffff8108f69d>] worker_thread+0x11d/0x5b0
        [<ffffffff8108f580>] ? rescuer_thread+0x3a0/0x3a0
        [<ffffffff81096811>] kthread+0xe1/0x100
        [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0
        [<ffffffff816cc6bc>] ret_from_fork+0x7c/0xb0
        [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0
      
      This patch fixes this problem by checking if acpi_device->handler is NULL
      in acpi_scan_hot_remove().
      
      Fixes: d22ddcbc (ACPI / hotplug: Add demand_offline hotplug profile flag)
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
      [rjw: Subject]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dee15926
  7. 24 7月, 2014 1 次提交
    • R
      ACPI / scan: No implicit wake notification for buttons · bd9b2f9a
      Rafael J. Wysocki 提交于
      The ACPI device enumeration code in Linux assumes that buttons always
      are wakeup devices, so it calls acpi_setup_gpe_for_wake() for them
      which leads to undesirable side effects.  Namely, that function sets
      up implicit device wake notification mechanism for a given GPE if
      there is no handler method in the ACPI namespace, which from the
      ACPICA's perspective means that there always is a way to handle
      that GPE if enabled.  However, we don't handle wake notify events
      for buttons, so if there are no handler methods for their GPEs in
      the namespace, enabling a button GPE at run time leads to a GPE
      storm in some cases (the GPE triggers, ACPICA carries out the
      implicit wake notification for it which isn't handled, so the
      GPE triggers again and so on).
      
      To prevent that from happening use acpi_mark_gpe_for_wake()
      instead of acpi_setup_gpe_for_wake() for buttons which will cause
      ACPICA to only enable button GPEs if there are handler methods for
      the in the namespace.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bd9b2f9a
  8. 16 7月, 2014 1 次提交
  9. 30 5月, 2014 5 次提交
    • Z
      ACPI / scan: use platform bus type by default for _HID enumeration · 48459340
      Zhang Rui 提交于
      Because of the growing demand for enumerating ACPI devices to
      platform bus, change the code to enumerate ACPI device objects to
      platform bus by default.  Namely, create platform devices for the
      ACPI device objects that
       1. Have pnp.type.platform_id set (device objects with _HID currently).
       2. Do not have a scan handler attached.
       3. Are not SPI/I2C slave devices (that should be enumerated to the
          appropriate buses bus by their parent).
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      [rjw: Subject and changelog, rebase and code cleanup]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      48459340
    • R
      ACPI / scan: Change the meaning of missing .attach() in scan handlers · d34afa9d
      Rafael J. Wysocki 提交于
      Currently, some scan handlers can be compiled out entirely, which
      leaves the device objects they normally attach to without a scan
      handler.  This isn't a problem as long as we don't have any default
      enumeration mechanism that applies to all devices without a scan
      handler.  However, if such a default enumeration is added, it still
      should not be applied to devices that are normally attached to by
      scan handlers, because that may result in creating "physical" device
      objects of a wrong type for them.
      
      Since we are going to create platform device objects for all ACPI
      device objects with pnp.type.platform_id set by default, clear
      pnp.type.platform_id where there is a matching scan handler without
      an .attach() callback and otherwise simply treat that scan handler
      as though the .attach() callback was present but always returned 0.
      
      This will allow us to compile out scan handler callbacks and leave
      the device ID lists used by them so as to prevent creating platform
      device objects for the matching ACPI devices.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      d34afa9d
    • R
      ACPI / scan: introduce platform_id device PNP type flag · 549e6845
      Rafael J. Wysocki 提交于
      Only certain types of ACPI device objects can be enumerated as
      platform devices, so in order to distinguish them from the others
      introduce a new ACPI device PNP type flag, platform_id, and set it
      for devices with a valid _HID to start with.
      
      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>
      549e6845
    • 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
  10. 20 5月, 2014 1 次提交
  11. 28 4月, 2014 1 次提交
  12. 05 3月, 2014 1 次提交
  13. 22 2月, 2014 2 次提交
  14. 21 2月, 2014 2 次提交
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 29 1月, 2014 1 次提交
  21. 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
  22. 11 1月, 2014 1 次提交
  23. 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
  24. 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
  25. 25 11月, 2013 1 次提交
  26. 23 11月, 2013 1 次提交