1. 29 6月, 2010 1 次提交
    • T
      acpi: use queue_work_on() instead of binding workqueue worker to cpu0 · 8fec62b2
      Tejun Heo 提交于
      ACPI works need to be executed on cpu0 and acpi/osl.c achieves this by
      creating singlethread workqueue and then binding it to cpu0 from a
      work which is quite unorthodox.  Make it create regular workqueues and
      use queue_work_on() instead.  This is in preparation of concurrency
      managed workqueue and the extra workers won't be a problem after it's
      implemented.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      8fec62b2
  2. 28 5月, 2010 1 次提交
    • J
      hwmon: (asus_atk0110) Don't load if ACPI resources aren't enforced · 70dd6bea
      Jean Delvare 提交于
      When the user passes the kernel parameter acpi_enforce_resources=lax,
      the ACPI resources are no longer protected, so a native driver can
      make use of them. In that case, we do not want the asus_atk0110 to be
      loaded. Unfortunately, this driver loads automatically due to its
      MODULE_DEVICE_TABLE, so the user ends up with two drivers loaded for
      the same device - this is bad.
      
      So I suggest that we prevent the asus_atk0110 driver from loading if
      acpi_enforce_resources=lax.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NLuca Tettamanti <kronos.it@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      70dd6bea
  3. 05 4月, 2010 1 次提交
  4. 23 3月, 2010 1 次提交
  5. 16 3月, 2010 1 次提交
  6. 28 1月, 2010 1 次提交
  7. 10 12月, 2009 1 次提交
  8. 27 9月, 2009 1 次提交
    • J
      ACPI: Clarify resource conflict message · 14f03343
      Jean Delvare 提交于
      The message "ACPI: Device needs an ACPI driver" is misleading. The
      device _may_ need an ACPI driver, if the BIOS implemented a custom
      API for the device in question (which, AFAIK, can't be checked.) If
      not, then either a generic ACPI driver may be used (for example
      "thermal"), or nothing can be done (other than a white list).
      
      I propose to reword the message to:
      
      ACPI: If an ACPI driver is available for this device, you should use
      it instead of the native driver
      
      which I think is more correct. Comments and suggestions welcome.
      
      I also added a message warning about possible problems and system
      instability when users pass acpi_enforce_resources=lax, as suggested
      by Len.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      14f03343
  9. 24 9月, 2009 1 次提交
  10. 19 9月, 2009 2 次提交
  11. 28 8月, 2009 1 次提交
    • L
      ACPICA: fix leak of acpi_os_validate_address · a5fe1a03
      Lin Ming 提交于
      http://bugzilla.kernel.org/show_bug.cgi?id=13620
      
      If the dynamic region is created and added to resource list over and over again,
      it has the potential to be a memory leak by growing the list every time.
      
      This patch fixes the memory leak, as below
      
      1) add a new field "count" to struct acpi_res_list.
      
         When inserting, if the region(addr, len) is already in the resource
         list, we just increase "count", otherwise, the region is inserted
         with count=1.
      
         When deleting, the "count" is decreased, if it's decreased to 0,
         the region is deleted from the resource list.
      
         With "count", the region with same address and length can only be
         inserted to the resource list once, so prevent potential memory leak.
      
      2) add a new function acpi_os_invalidate_address, which is called when
         region is deleted.
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a5fe1a03
  12. 03 8月, 2009 1 次提交
  13. 24 6月, 2009 1 次提交
  14. 21 4月, 2009 1 次提交
  15. 03 4月, 2009 1 次提交
  16. 16 3月, 2009 1 次提交
  17. 23 2月, 2009 1 次提交
  18. 09 2月, 2009 1 次提交
    • Y
      acpi/x86: introduce __apci_map_table, v4 · 7d97277b
      Yinghai Lu 提交于
      to prevent wrongly overwriting fixmap that still want to use.
      
      ACPI used to rely on low mappings being all linearly mapped and
      grew a habit: it never really unmapped certain kinds of tables
      after use.
      
      This can cause problems - for example the hypothetical case
      when some spurious access still references it.
      
      v2: remove prev_map and prev_size in __apci_map_table
      v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
      early_acpi_os_unmap_memory
      v4: fix typo in one acpi_get_table_with_size calling
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7d97277b
  19. 07 2月, 2009 1 次提交
  20. 04 2月, 2009 1 次提交
  21. 31 12月, 2008 1 次提交
  22. 27 11月, 2008 1 次提交
  23. 23 10月, 2008 1 次提交
  24. 11 10月, 2008 1 次提交
  25. 24 9月, 2008 1 次提交
    • Z
      ACPI: fix hotplug race · 19cd847a
      Zhang Rui 提交于
      The hotplug notification handler and drivers' notification handler all
      run in one workqueue.  Before hotplug removes an acpi device, the
      device driver's notification handler is already be recorded to run just
      after global notification handler.  After hotplug notification handler
      runs, acpica will notice a NULL notification handler and crash.
      
      So now we run run hotplug in another workqueue and wait
      for all acpi notication handlers finish.
      This was found in battery hotplug, but actually all
      hotplug can be affected.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      19cd847a
  26. 29 4月, 2008 1 次提交
  27. 17 4月, 2008 1 次提交
  28. 16 3月, 2008 1 次提交
    • L
      ACPI: Remove ACPI_CUSTOM_DSDT_INITRD option · 9a9e0d68
      Linus Torvalds 提交于
      This essentially reverts commit 71fc47a9
      ("ACPI: basic initramfs DSDT override support"), because the code simply
      isn't ready.
      
      It did ugly things to the init sequence to populate the rootfs image
      early, but that just ended up showing other problems with the whole
      approach.  The fact is, the VFS layer simply isn't initialized this
      early, and the relevant ACPI code should either run much later, or this
      shouldn't be done at all.
      
      For 2.6.25, we'll just pick the latter option.  We can revisit this
      concept later if necessary.
      
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Eric Piel <eric.piel@tremplin-utc.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Markus Gaugusch <dsdt@gaugusch.at>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a9e0d68
  29. 11 3月, 2008 1 次提交
  30. 14 2月, 2008 4 次提交
  31. 11 2月, 2008 1 次提交
  32. 08 2月, 2008 1 次提交
  33. 07 2月, 2008 4 次提交