1. 10 4月, 2015 3 次提交
  2. 18 3月, 2015 1 次提交
  3. 06 2月, 2015 1 次提交
  4. 06 1月, 2015 1 次提交
    • R
      ACPI / PM: Fix PM initialization for devices that are not present · 1b1f3e16
      Rafael J. Wysocki 提交于
      If an ACPI device object whose _STA returns 0 (not present and not
      functional) has _PR0 or _PS0, its power_manageable flag will be set
      and acpi_bus_init_power() will return 0 for it.  Consequently, if
      such a device object is passed to the ACPI device PM functions, they
      will attempt to carry out the requested operation on the device,
      although they should not do that for devices that are not present.
      
      To fix that problem make acpi_bus_init_power() return an error code
      for devices that are not present which will cause power_manageable to
      be cleared for them as appropriate in acpi_bus_get_power_flags().
      However, the lists of power resources should not be freed for the
      device in that case, so modify acpi_bus_get_power_flags() to keep
      those lists even if acpi_bus_init_power() returns an error.
      Accordingly, when deciding whether or not the lists of power
      resources need to be freed, acpi_free_power_resources_lists()
      should check the power.flags.power_resources flag instead of
      flags.power_manageable, so make that change too.
      
      Furthermore, if acpi_bus_attach() sees that flags.initialized is
      unset for the given device, it should reset the power management
      settings of the device and re-initialize them from scratch instead
      of relying on the previous settings (the device may have appeared
      after being not present previously, for example), so make it use
      the 'valid' flag of the D0 power state as the initial value of
      flags.power_manageable for it and call acpi_bus_init_power() to
      discover its current power state.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
      1b1f3e16
  5. 13 12月, 2014 1 次提交
  6. 24 11月, 2014 1 次提交
  7. 05 11月, 2014 3 次提交
  8. 28 10月, 2014 1 次提交
    • M
      ACPI: Use ACPI companion to match only the first physical device · 52870786
      Mika Westerberg 提交于
      Commit 6ab34301 ("mfd: Add ACPI support") made the MFD subdevices
      share the parent MFD ACPI companion if no _HID/_CID is specified for
      the subdevice in mfd_cell description. However, since all the subdevices
      share the ACPI companion, the match and modalias generation logic started
      to use the ACPI companion as well resulting this:
      
        # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
        acpi:INT33D1:PNP0C50:
      
      instead of the expected one
      
        # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
        platform:HID-SENSOR-200041
      
      In other words the subdevice modalias is overwritten by the one taken from
      ACPI companion. This causes udev not to load the driver anymore.
      
      It is useful to be able to share the ACPI companion so that MFD subdevices
      (and possibly other devices as well) can access the ACPI resources even if
      they do not have ACPI representation in the namespace themselves.
      
      An example where this is used is Minnowboard LPC driver that creates GPIO
      as a subdevice among other things. Without the ACPI companion gpiolib is
      not able to lookup the corresponding GPIO controller from ACPI GpioIo
      resource.
      
      To fix this, restrict the match and modalias logic to be limited to the
      first (primary) physical device associated with the given ACPI comapnion.
      The secondary devices will still be able to access the ACPI companion,
      but they will be matched in a different way.
      
      Fixes: 6ab34301 (mfd: Add ACPI support)
      Reported-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      52870786
  9. 21 10月, 2014 1 次提交
  10. 22 9月, 2014 1 次提交
  11. 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
  12. 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
  13. 04 9月, 2014 1 次提交
  14. 26 8月, 2014 2 次提交
  15. 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
  16. 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
  17. 16 7月, 2014 1 次提交
  18. 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
  19. 20 5月, 2014 1 次提交
  20. 28 4月, 2014 1 次提交
  21. 05 3月, 2014 1 次提交
  22. 22 2月, 2014 2 次提交
  23. 21 2月, 2014 2 次提交
  24. 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
  25. 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
  26. 07 2月, 2014 3 次提交