1. 20 8月, 2013 3 次提交
  2. 08 8月, 2013 2 次提交
    • R
      ACPI: Try harder to resolve _ADR collisions for bridges · 60f75b8e
      Rafael J. Wysocki 提交于
      In theory, under a given ACPI namespace node there should be only
      one child device object with _ADR whose value matches a given bus
      address exactly.  In practice, however, there are systems in which
      multiple child device objects under a given parent have _ADR matching
      exactly the same address.  In those cases we use _STA to determine
      which of the multiple matching devices is enabled, since some systems
      are known to indicate which ACPI device object to associate with the
      given physical (usually PCI) device this way.
      
      Unfortunately, as it turns out, there are systems in which many
      device objects under the same parent have _ADR matching exactly the
      same bus address and none of them has _STA, in which case they all
      should be regarded as enabled according to the spec.  Still, if
      those device objects are supposed to represent bridges (e.g. this
      is the case for device objects corresponding to PCIe ports), we can
      try harder and skip the ones that have no child device objects in the
      ACPI namespace.  With luck, we can avoid using device objects that we
      are not expected to use this way.
      
      Although this only works for bridges whose children also have ACPI
      namespace representation, it is sufficient to address graphics
      adapter detection issues on some systems, so rework the code finding
      a matching device ACPI handle for a given bus address to implement
      this idea.
      
      Introduce a new function, acpi_find_child(), taking three arguments:
      the ACPI handle of the device's parent, a bus address suitable for
      the device's bus type and a bool indicating if the device is a
      bridge and make it work as outlined above.  Reimplement the function
      currently used for this purpose, acpi_get_child(), as a call to
      acpi_find_child() with the last argument set to 'false' and make
      the PCI subsystem use acpi_find_child() with the bridge information
      passed as the last argument to it.  [Lan Tianyu notices that it is
      not sufficient to use pci_is_bridge() for that, because the device's
      subordinate pointer hasn't been set yet at this point, so use
      hdr_type instead.]
      
      This change fixes a regression introduced inadvertently by commit
      33f767d7 (ACPI: Rework acpi_get_child() to be more efficient) which
      overlooked the fact that for acpi_walk_namespace() "post-order" means
      "after all children have been visited" rather than "on the way back",
      so for device objects without children and for namespace walks of
      depth 1, as in the acpi_get_child() case, the "post-order" callbacks
      ordering is actually the same as the ordering of "pre-order" ones.
      Since that commit changed the namespace walk in acpi_get_child() to
      terminate after finding the first matching object instead of going
      through all of them and returning the last one, it effectively
      changed the result returned by that function in some rare cases and
      that led to problems (the switch from a "pre-order" to a "post-order"
      callback was supposed to prevent that from happening, but it was
      ineffective).
      
      As it turns out, the systems where the change made by commit
      33f767d7 actually matters are those where there are multiple ACPI
      device objects representing the same PCIe port (which effectively
      is a bridge).  Moreover, only one of them, and the one we are
      expected to use, has child device objects in the ACPI namespace,
      so the regression can be addressed as described above.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=60561Reported-by: NPeter Wu <lekensteyn@gmail.com>
      Tested-by: NVladimir Lalov <mail@vlalov.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
      60f75b8e
    • Y
      ACPI / processor: move try_offline_node() after acpi_unmap_lsapic() · 1e385f6f
      Yasuaki Ishimatsu 提交于
      try_offline_node() checks that all CPUs associated with the given
      node have been removed by using cpu_present_bits.  If all cpus
      related to that node have been removed, try_offline_node() clears
      the node information.
      
      However, try_offline_node() called from acpi_processor_remove() never
      clears the node information.  For disabling cpu_present_bits,
      acpi_unmap_lsapic() needs be called.  Yet, acpi_unmap_lsapic() is
      called after try_offline_node() has run.  So when try_offline_node()
      runs, the CPU's cpu_present_bits is always set.
      
      Fix the issue by moving try_offline_node() after acpi_unmap_lsapic().
      
      The problem fixed here was uncovered by commit cecdb193 "ACPI / scan:
      Change the implementation of acpi_bus_trim()".
      
      [rjw: Changelog]
      Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1e385f6f
  3. 06 8月, 2013 2 次提交
    • R
      ACPI: Drop physical_node_id_bitmap from struct acpi_device · 007ccfcf
      Rafael J. Wysocki 提交于
      The physical_node_id_bitmap in struct acpi_device is only used for
      looking up the first currently unused dependent phyiscal node ID
      by acpi_bind_one().  It is not really necessary, however, because
      acpi_bind_one() walks the entire physical_node_list of the given
      device object for sanity checking anyway and if that list is always
      sorted by node_id, it is straightforward to find the first gap
      between the currently used node IDs and use that number as the ID
      of the new list node.
      
      This also removes the artificial limit of the maximum number of
      dependent physical devices per ACPI device object, which now depends
      only on the capacity of unsigend int.  As a result, it fixes a
      regression introduced by commit e2ff3940 (ACPI / memhotplug: Bind
      removable memory blocks to ACPI device nodes) that caused
      acpi_memory_enable_device() to fail when the number of 128 MB blocks
      within one removable memory module was greater than 32.
      Reported-and-tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      007ccfcf
    • R
      ACPI / PM: Walk physical_node_list under physical_node_lock · 623cf33c
      Rafael J. Wysocki 提交于
      The list of physical devices corresponding to an ACPI device
      object is walked by acpi_system_wakeup_device_seq_show() and
      physical_device_enable_wakeup() without taking that object's
      physical_node_lock mutex.  Since each of those functions may be
      run at any time as a result of a user space action, the lack of
      appropriate locking in them may lead to a kernel crash if that
      happens during device hot-add or hot-remove involving the device
      object in question.
      
      Fix the issue by modifying acpi_system_wakeup_device_seq_show() and
      physical_device_enable_wakeup() to use physical_node_lock as
      appropriate.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: All <stable@vger.kernel.org>
      623cf33c
  4. 05 8月, 2013 1 次提交
    • F
      ACPI / video: improve quirk check in acpi_video_bqc_quirk() · b3b301c5
      Felipe Contreras 提交于
      If the _BCL package ordering is descending, the first level
      (br->levels[2]) is likely to be 0, and if the number of levels
      matches the number of steps, we might confuse a returned level to
      mean the index.
      
      For example:
      
        current_level = max_level = 100
        test_level = 0
        returned level = 100
      
      In this case 100 means the level, not the index, and _BCM failed.
      Still, if the _BCL package ordering is descending, the index of
      level 0 is also 100, so we assume _BQC is indexed, when it's not.
      
      This causes all _BQC calls to return bogus values causing weird
      behavior from the user's perspective.  For example:
      
      xbacklight -set 10; xbacklight -set 20;
      
      would flash to 90% and then slowly down to the desired level (20).
      
      The solution is simple; test anything other than the first level
      (e.g. 1).
      
      [rjw: Changelog]
      Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b3b301c5
  5. 30 7月, 2013 1 次提交
  6. 26 7月, 2013 1 次提交
  7. 19 7月, 2013 1 次提交
  8. 18 7月, 2013 4 次提交
  9. 15 7月, 2013 4 次提交
  10. 05 7月, 2013 1 次提交
  11. 04 7月, 2013 5 次提交
    • N
      ACPI / fan: Initialize acpi_state variable · 85eb9827
      Naresh Bhat 提交于
      Make the following compiler warning go away:
      
       CC      drivers/acpi/fan.o
      drivers/acpi/fan.c: In function ‘fan_get_cur_state’:
      drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized]
      
      by initializing the local variable acpi_state in fan_get_cur_state().
      
      [rjw: Changelog]
      Signed-off-by: NNaresh Bhat <naresh.bhat@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      85eb9827
    • H
      ACPI / scan: remove unused LIST_HEAD(acpi_device_list) · b67cf7c4
      Haicheng Li 提交于
      The acpi_device_list list is not used, so removed it.
      
      [rjw: Changelog]
      Signed-off-by: NHaicheng Li <haicheng.li@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b67cf7c4
    • R
      ACPI / dock: Actually define acpi_dock_init() as void · 2ce65fe8
      Rafael J. Wysocki 提交于
      Commit 94add0f8 (ACPI / dock: Initialize ACPI dock subsystem upfront)
      changed the header of acpi_dock_init() in internal.h so that it is
      supposed to be a void function now, but it forgot to update its
      actual definition in dock.c according to which it still is supposed
      to return int.
      
      Although that didn't cause any visible breakage or even a compiler
      warning to be thrown, which is odd enough, fix it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.10+ <stable@vger.kernel.org>
      2ce65fe8
    • R
      ACPI / PM: Fix corner case in acpi_bus_update_power() · 91bdad0b
      Rafael J. Wysocki 提交于
      The role of acpi_bus_update_power() is to update the given ACPI
      device object's power.state field to reflect the current physical
      state of the device (as inferred from the configuration of power
      resources and _PSC, if available).  For this purpose it calls
      acpi_device_set_power() that should update the power resources'
      reference counters and set power.state as appropriate.  However,
      that doesn't work if the "new" state is D1, D2 or D3hot and the
      the current value of power.state means D3cold, because in that
      case acpi_device_set_power() will refuse to transition the device
      from D3cold to non-D0.
      
      To address this problem, make acpi_bus_update_power() call
      acpi_power_transition() directly to update the power resources'
      reference counters and only use acpi_device_set_power() to put
      the device into D0 if the current physical state of it cannot
      be determined.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      91bdad0b
    • K
      clean up scary strncpy(dst, src, strlen(src)) uses · 096a8aac
      Kees Cook 提交于
      Fix various weird constructions of strncpy(dst, src, strlen(src)).
      
      Length limits should be about the space available in the destination,
      not repurposed as a method to either always include or always exclude a
      trailing NULL byte.  Either the NULL should always be copied (using
      strlcpy), or it should not be copied (using something like memcpy).
      Readable code should not depend on the weird behavior of strncpy when it
      hits the length limit.  Better to avoid the anti-pattern entirely.
      
      [akpm@linux-foundation.org: revert getdelays.c part due to missing bsd/string.h]
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	[staging]
      Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>	[acpi]
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ursula Braun <ursula.braun@de.ibm.com>
      Cc: Frank Blaschka <blaschka@linux.vnet.ibm.com>
      Cc: Richard Weinberger <richard@nod.at>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      096a8aac
  12. 01 7月, 2013 1 次提交
  13. 29 6月, 2013 1 次提交
    • L
      acpi: Eliminate console msg if pstore.backend excludes ERST · 74fd6c6f
      Lenny Szubowicz 提交于
      This is patch 2/3 of a patch set that avoids what misleadingly appears
      to be a error during boot:
      
      ERST: Could not register with persistent store
      
      This message is displayed if the system has a valid ACPI ERST table and the
      pstore.backend kernel parameter has been used to disable use of ERST by
      pstore. But this same message is used for errors that preclude registration.
      
      In erst_init don't complain if the setting of kernel parameter pstore.backend
      precludes use of ACPI ERST for pstore. Routine pstore_register will inform
      about the facility that does register.
      
      Also, don't leave a dangling pointer to deallocated mem for the pstore
      buffer when registration fails.
      Signed-off-by: NLenny Szubowicz <lszubowi@redhat.com>
      Reported-by: NNaotaka Hamaguchi <n.hamaguchi@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      74fd6c6f
  14. 28 6月, 2013 4 次提交
  15. 26 6月, 2013 1 次提交
  16. 24 6月, 2013 2 次提交
    • H
      ACPI / processor: Remove unused macros in processor_driver.c · 86d6725a
      Hanjun Guo 提交于
      ACPI_PROCESSOR_FILE_INFO, ACPI_PROCESSOR_FILE_THROTTLING and
      ACPI_PROCESSOR_FILE_LIMIT are used for procfs, but this feature was removed
      in commit d09fe555 (ACPI processor: remove deprecated ACPI procfs I/F) long
      ago. So, these macros should also be removed.
      
      ACPI_PROCESSOR_LIMIT_USER and ACPI_PROCESSOR_LIMIT_THERMAL are not used
      by any code, remove them too.
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      86d6725a
    • R
      ACPI / dock / PCI: Synchronous handling of dock events for PCI devices · 21a31013
      Rafael J. Wysocki 提交于
      The interactions between the ACPI dock driver and the ACPI-based PCI
      hotplug (acpiphp) are currently problematic because of ordering
      issues during hot-remove operations.
      
      First of all, the current ACPI glue code expects that physical
      devices will always be deleted before deleting the companion ACPI
      device objects.  Otherwise, acpi_unbind_one() will fail with a
      warning message printed to the kernel log, for example:
      
      [  185.026073] usb usb5: Oops, 'acpi_handle' corrupt
      [  185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt
      [  185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt
      [  180.013656]  port1: Oops, 'acpi_handle' corrupt
      
      This means, in particular, that struct pci_dev objects have to
      be deleted before the struct acpi_device objects they are "glued"
      with.
      
      Now, the following happens the during the undocking of an ACPI-based
      dock station:
       1) hotplug_dock_devices() invokes registered hotplug callbacks to
          destroy physical devices associated with the ACPI device objects
          depending on the dock station.  It calls dd->ops->handler() for
          each of those device objects.
       2) For PCI devices dd->ops->handler() points to
          handle_hotplug_event_func() that queues up a separate work item
          to execute _handle_hotplug_event_func() for the given device and
          returns immediately.  That work item will be executed later.
       3) hotplug_dock_devices() calls dock_remove_acpi_device() for each
          device depending on the dock station.  This runs acpi_bus_trim()
          for each of them, which causes the underlying ACPI device object
          to be destroyed, but the work items queued up by
          handle_hotplug_event_func() haven't been started yet.
       4) _handle_hotplug_event_func() queued up in step 2) are executed
          and cause the above failure to happen, because the PCI devices
          they handle do not have the companion ACPI device objects any
          more (those objects have been deleted in step 3).
      
      The possible breakage doesn't end here, though, because
      hotplug_dock_devices() may return before at least some of the
      _handle_hotplug_event_func() work items spawned by it have a
      chance to complete and then undock() will cause _DCK to be
      evaluated and that will cause the devices handled by the
      _handle_hotplug_event_func() to go away possibly while they are
      being accessed.
      
      This means that dd->ops->handler() for PCI devices should not point
      to handle_hotplug_event_func().  Instead, it should point to a
      function that will do the work of _handle_hotplug_event_func()
      synchronously.  For this reason, introduce such a function,
      hotplug_event_func(), and modity acpiphp_dock_ops to point to
      it as the handler.
      
      Unfortunately, however, this is not sufficient, because if the dock
      code were not changed further, hotplug_event_func() would now
      deadlock with hotplug_dock_devices() that called it, since it would
      run unregister_hotplug_dock_device() which in turn would attempt to
      acquire the dock station's hp_lock mutex already acquired by
      hotplug_dock_devices().
      
      To resolve that deadlock use the observation that
      unregister_hotplug_dock_device() won't need to acquire hp_lock
      if PCI bridges the devices on the dock station depend on are
      prevented from being removed prematurely while the first loop in
      hotplug_dock_devices() is in progress.
      
      To make that possible, introduce a mechanism by which the callers of
      register_hotplug_dock_device() can provide "init" and "release"
      routines that will be executed, respectively, during the addition
      and removal of the physical device object associated with the
      given ACPI device handle.  Make acpiphp use two new functions,
      acpiphp_dock_init() and acpiphp_dock_release(), that call
      get_bridge() and put_bridge(), respectively, on the acpiphp bridge
      holding the given device, for this purpose.
      
      In addition to that, remove the dock station's list of
      "hotplug devices" and make the dock code always walk the whole list
      of "dependent devices" instead in such a way that the loops in
      hotplug_dock_devices() and dock_event() (replacing the loops over
      "hotplug devices") will take references to the list entries that
      register_hotplug_dock_device() has been called for.  That prevents
      the "release" routines associated with those entries from being
      called while the given entry is being processed and for PCI
      devices this means that their bridges won't be removed (by a
      concurrent thread) while hotplug_event_func() handling them is
      being executed.
      
      This change is based on two earlier patches from Jiang Liu.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59501Reported-and-tested-by: NAlexander E. Patrakov <patrakov@gmail.com>
      Tracked-down-by: NJiang Liu <jiang.liu@huawei.com>
      Tested-by: NIllya Klymov <xanf@xanf.me>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Cc: 3.9+ <stable@vger.kernel.org>
      21a31013
  17. 23 6月, 2013 1 次提交
  18. 20 6月, 2013 5 次提交