1. 26 1月, 2013 1 次提交
  2. 15 11月, 2012 2 次提交
  3. 03 10月, 2012 1 次提交
  4. 17 7月, 2012 1 次提交
  5. 01 6月, 2012 1 次提交
  6. 22 3月, 2012 2 次提交
  7. 21 1月, 2012 1 次提交
    • M
      ACPI, APEI: Add 64-bit read/write support for APEI on i386 · e615bf5b
      Myron Stowe 提交于
      Base ACPI (CA) currently does not support atomic 64-bit reads and writes
      (acpi_read() and acpi_write() split 64-bit loads/stores into two
      32-bit transfers) yet APEI expects 64-bit transfer capability, even
      when running on 32-bit systems.
      
      This patch implements 64-bit read and write routines for APEI usage.
      
      This patch re-factors similar functionality introduced in commit
      04c25997, bringing it into the ACPI subsystem in preparation for
      removing ./drivers/acpi/atomicio.[ch].  In the implementation I have
      replicated acpi_os_read_memory() and acpi_os_write_memory(), creating
      64-bit versions for APEI to utilize, as opposed to something more
      elegant.  My thinking is that we should attempt to see if we can get
      ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write()
      interfaces are natively 64-bit capable and then subsequently remove the
      replication.
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e615bf5b
  8. 17 1月, 2012 1 次提交
  9. 15 10月, 2011 1 次提交
    • P
      PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove · 6af8bef1
      Prarit Bhargava 提交于
      I originally submitted a patch to workaround this by pushing all Ejection
      Requests and Device Checks onto the kacpi_hotplug queue.
      
      http://marc.info/?l=linux-acpi&m=131678270930105&w=2
      
      The patch is still insufficient in that Bus Checks also need to be added.
      
      Rather than add all events, including non-PCI-hotplug events, to the
      hotplug queue, mjg suggested that a better approach would be to modify
      the acpiphp driver so only acpiphp events would be added to the
      kacpi_hotplug queue.
      
      It's a longer patch, but at least we maintain the benefit of having separate
      queues in ACPI.  This, of course, is still only a workaround the problem.
      As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
      the right thing but at this point it is a better to have this code working.
      
      The acpi core places all events on the kacpi_notify queue.  When the acpiphp
      driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
      following call sequence occurs:
      
      cleanup_p2p_bridge()
      	    -> cleanup_bridge()
      		    -> acpi_remove_notify_handler()
      			    -> acpi_os_wait_events_complete()
      				    -> flush_workqueue(kacpi_notify_wq)
      
      which is the queue we are currently executing on and the process will hang.
      
      Move all hotplug acpiphp events onto the kacpi_hotplug workqueue.  In
      handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
      push the rest of the work onto the kacpi_hotplug queue and then avoid the
      deadlock.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: mjg@redhat.com
      Cc: bhelgaas@google.com
      Cc: linux-acpi@vger.kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6af8bef1
  10. 14 7月, 2011 1 次提交
  11. 25 3月, 2011 1 次提交
  12. 19 1月, 2011 1 次提交
  13. 20 10月, 2010 1 次提交
  14. 01 10月, 2010 3 次提交
  15. 06 5月, 2010 1 次提交
  16. 23 1月, 2010 2 次提交
  17. 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
  18. 28 7月, 2009 1 次提交
  19. 28 3月, 2009 1 次提交
  20. 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
  21. 31 12月, 2008 1 次提交
  22. 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
  23. 17 7月, 2008 1 次提交
  24. 24 4月, 2008 1 次提交
  25. 14 2月, 2008 1 次提交
  26. 07 2月, 2008 2 次提交
    • T
      ACPI: track opregion names to avoid driver resource conflicts. · df92e695
      Thomas Renninger 提交于
      Small ACPICA extension to be able to store the name of operation regions in osl.c later
      
      In ACPI, AML can define accesses to IO ports and System Memory by Operation
      Regions.  Those are not registered as done by PNPACPI using resource templates
      (and _CRS/_SRS methods).
      
      The IO ports and System Memory regions may get accessed by arbitrary AML code.
       When native drivers are accessing the same resources bad things can happen
      (e.g.  a critical shutdown temperature of 3000 C every 2 months or so).
      
      It is not really possible to register the operation regions via
      request_resource, as they often overlap with pnp or other resources (e.g.
      statically setup IO resources below 0x100).
      
      This approach stores all Operation Region declarations (IO and System Memory
      only) at ACPI table parse time.  It offers a similar functionality like
      request_region and let drivers which are known to possibly use the same IO
      ports and Memory which are also often used by ACPI (hwmon and i2c) check for
      ACPI interference.
      
      A boot parameter acpi_enforce_resources=strict/lax/no is provided, which
      is default set to lax:
        - strict: let conflicting drivers fail to load with an error message
        - lax:    let conflicting driver work normal with a warning message
        - no:     no functional change at all
      Depending on the feedback and the kind of interferences we see, this
      should be set to strict at later time.
      
      Goal of this patch set is:
        - Identify ACPI interferences in bug reports (very hard to reproduce
          and to identify)
        - Find BIOSes for that an ACPI driver should exist for specific HW
          instead of a native one.
        - stability in general
      
      Provide acpi_check_{mem_}region.
      
      Drivers can additionally check against possible ACPI interference by also
      invoking this shortly before they call request_region.
      If -EBUSY is returned, the driver must not load.
      Use acpi_enforce_resources=strict/lax/no options to:
        - strict: let conflicting drivers fail to load with an error message
        - lax:    let conflicting driver work normal with a warning message
        - no:     no functional change at all
      
      Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      df92e695
    • L
      ACPI: create /sys/firmware/acpi/interrupts · 5229e87d
      Len Brown 提交于
      See Documentation/ABI/testing/sysfs-firmware-acpi
      Based-on-original-patch-by: NLuming Yu <luming.yu@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      5229e87d
  27. 30 5月, 2007 2 次提交
  28. 10 5月, 2007 1 次提交
  29. 16 2月, 2007 1 次提交
  30. 03 2月, 2007 2 次提交
  31. 30 6月, 2006 1 次提交
  32. 28 6月, 2006 1 次提交
    • B
      ACPI: ACPICA 20060623 · 967440e3
      Bob Moore 提交于
      Implemented a new acpi_spinlock type for the OSL lock
      interfaces.  This allows the type to be customized to
      the host OS for improved efficiency (since a spinlock is
      usually a very small object.)
      
      Implemented support for "ignored" bits in the ACPI
      registers.  According to the ACPI specification, these
      bits should be preserved when writing the registers via
      a read/modify/write cycle. There are 3 bits preserved
      in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9],
      and PM1_STATUS[11].
      http://bugzilla.kernel.org/show_bug.cgi?id=3691
      
      Implemented the initial deployment of new OSL mutex
      interfaces.  Since some host operating systems have
      separate mutex and semaphore objects, this feature was
      requested. The base code now uses mutexes (and the new
      mutex interfaces) wherever a binary semaphore was used
      previously. However, for the current release, the mutex
      interfaces are defined as macros to map them to the
      existing semaphore interfaces.
      
      Fixed several problems with the support for the control
      method SyncLevel parameter. The SyncLevel now works
      according to the ACPI specification and in concert with the
      Mutex SyncLevel parameter, since the current SyncLevel is
      a property of the executing thread. Mutual exclusion for
      control methods is now implemented with a mutex instead
      of a semaphore.
      
      Fixed three instances of the use of the C shift operator
      in the bitfield support code (exfldio.c) to avoid the use
      of a shift value larger than the target data width. The
      behavior of C compilers is undefined in this case and can
      cause unpredictable results, and therefore the case must
      be detected and avoided.  (Fiodor Suietov)
      
      Added an info message whenever an SSDT or OEM table
      is loaded dynamically via the Load() or LoadTable()
      ASL operators. This should improve debugging capability
      since it will show exactly what tables have been loaded
      (beyond the tables present in the RSDT/XSDT.)
      Signed-off-by: NBob Moore <robert.moore@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      967440e3