1. 25 2月, 2011 5 次提交
  2. 09 2月, 2011 1 次提交
    • R
      ACPI: Fix acpi_os_read_memory() and acpi_os_write_memory() (v2) · 884b821f
      Rafael J. Wysocki 提交于
      The functions acpi_os_read_memory() and acpi_os_write_memory() do
      two wrong things.  First, they shouldn't call rcu_read_unlock()
      before the looked up address is actually used for I/O, because in
      that case the iomap it belongs to may be removed before the I/O
      is done.  Second, if they have to create a new mapping, they should
      check the returned virtual address and tell the caller that the
      operation failed if it is NULL (in fact, I think they even should not
      attempt to map an address that's not present in one of the existing
      ACPI iomaps, because that may cause problems to happen when they are
      called from nonpreemptible context and their callers ought to know
      what they are doing and map the requisite memory regions beforehand).
      
      Make these functions call rcu_read_unlock() when the I/O is complete
      (or if it's necessary to map the given address "on the fly") and
      return an error code if the requested physical address is not present
      in the existing ACPI iomaps and cannot be mapped.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      884b821f
  3. 21 1月, 2011 1 次提交
    • R
      ACPI: Introduce acpi_os_ioremap() · 2d6d9fd3
      Rafael J. Wysocki 提交于
      Commit ca9b600b ("ACPI / PM: Make suspend_nvs_save() use
      acpi_os_map_memory()") attempted to prevent the code in osl.c and nvs.c
      from using different ioremap() variants by making the latter use
      acpi_os_map_memory() for mapping the NVS pages.  However, that also
      requires acpi_os_unmap_memory() to be used for unmapping them, which
      causes synchronize_rcu() to be executed many times in a row
      unnecessarily and introduces substantial delays during resume on some
      systems.
      
      Instead of using acpi_os_map_memory() for mapping the NVS pages in nvs.c
      introduce acpi_os_ioremap() calling ioremap_cache() and make the code in
      both osl.c and nvs.c use it.
      Reported-by: NJeff Chua <jeff.chua.linux@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d6d9fd3
  4. 13 1月, 2011 1 次提交
  5. 07 1月, 2011 1 次提交
    • L
      ACPI: Use ioremap_cache() · 6d5bbf00
      Len Brown 提交于
      Although the temporary boot-time ACPI table mappings
      were set up with CPU caching enabled, the permanent table
      mappings and AML run-time region memory accesses were
      set up with ioremap(), which on x86 is a synonym for
      ioremap_nocache().
      
      Changing this to ioremap_cache() improves performance as
      seen when accessing the tables via acpidump,
      or /sys/firmware/acpi/tables.  It should also improve
      AML run-time performance.
      
      No change on ia64.
      Reported-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      6d5bbf00
  6. 11 12月, 2010 3 次提交
    • Z
      ACPI: fix a section mismatch · 32d47eef
      Zhang Rui 提交于
      WARNING: drivers/acpi/acpi.o(.text+0xeda): Section mismatch in reference from the function acpi_os_initialize1() to the function .init.text:set_osi_linux()
      
      The function acpi_os_initialize1() references
      the function __init set_osi_linux().
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      32d47eef
    • L
      ACPI: fix allowing to add/remove multiple _OSI strings · 12d32064
      Lin Ming 提交于
      commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
      introduced another regression that only one _OSI string can be added or
      removed.
      
      Now multiple _OSI strings can be added or removed, for example
      
      acpi_osi=Linux acpi_osi=FreeBSD acpi_osi="!Windows 2006"
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      12d32064
    • L
      acpi: fix _OSI string setup regression · d90aa92c
      Lin Ming 提交于
      commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
      introduced a regression that _OSI string setup fails.
      
      There are 2 paths to setup _OSI string.
      
      DMI:
      acpi_dmi_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI
      string to osi_setup_string
      
      Boot command line:
      acpi_osi_setup -> copy _OSI string to osi_setup_string
      
      Later, acpi_osi_setup_late will be called to handle osi_setup_string.
      If _OSI string is "Linux" or "!Linux", then the call path is,
      
      acpi_osi_setup_late -> acpi_cmdline_osi_linux -> set_osi_linux ->
      acpi_osi_setup -> copy _OSI string to osi_setup_string
      
      This actually never installs _OSI string(acpi_install_interface not
      called), but just copy the _OSI string to osi_setup_string.
      
      This patch fixes the regression.
      Reported-and-tested-by: NLukas Hejtmanek <xhejtman@ics.muni.cz>
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d90aa92c
  7. 25 10月, 2010 6 次提交
    • M
      ACPI: Page based coalescing of I/O remappings optimization · 4a3cba5e
      Myron Stowe 提交于
      This patch optimizes ACPI MMIO remappings by keeping track of the
      remappings on a PAGE_SIZE granularity.
      
      When an ioremap() occurs, the underlying infrastructure works on a 'page'
      based granularity.  As such, an ioremap() request for 1 byte for example,
      will end up mapping in an entire (PAGE_SIZE) page.  Huang Ying took
      advantage of this in commit 15651291 by
      checking if subsequent ioremap() requests reside within any of the list's
      existing remappings still in place, and if so, incrementing a reference
      count on the existing mapping as opposed to performing another ioremap().
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4a3cba5e
    • M
      ACPI: Convert simple locking to RCU based locking · 78cdb3ed
      Myron Stowe 提交于
      Convert the simple locking introduced earlier for the ACPI MMIO
      remappings list to an RCU based locking scheme.
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      78cdb3ed
    • M
      ACPI: Pre-map 'system event' related register blocks · d362edaf
      Myron Stowe 提交于
      During ACPI initialization, pre-map fixed hardware registers that are
      accessed during ACPI's 'system event' related IRQ handing.
      
      ACPI's 'system event' handing accesses specific fixed hardware
      registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
      blocks which are declared within the FADT.  If these registers are
      backed by MMIO, as opposed to I/O port space, accessing them within
      interrupt context will cause a panic as acpi_os_read_memory()
      depends on ioremap() in such cases - BZ 18012.
      
      By utilizing the functionality provided in the previous two patches -
      ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
      Add interfaces for ioremapping/iounmapping ACPI registers - accesses
      to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
      and/or NMI) provided the area was pre-mapped.  This solves BZ 18012.
      
      ACPI "System Event" reference(s):
        ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
        3.8 "System Events", 5.6 "ACPI Event Programming Model".
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
      
      Reported-by: <bjorn.helgaas@hp.com>
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d362edaf
    • M
      ACPI: Add interfaces for ioremapping/iounmapping ACPI registers · 29718521
      Myron Stowe 提交于
      Add remapping and unmapping interfaces for ACPI registers that are
      backed by memory mapped I/O (MMIO).  These interfaces, along with
      the MMIO remapping list, enable accesses of such registers from within
      interrupt context.
      
      ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
      hardware registers use the GAS format):
        ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
        Structure".
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      29718521
    • M
      ACPI: Maintain a list of ACPI memory mapped I/O remappings · 620242ae
      Myron Stowe 提交于
      For memory mapped I/O (MMIO) remappings, add a list to maintain the
      remappings and augment the corresponding mapping and unmapping interface
      routines (acpi_os_map_memory() and acpi_os_unmap_memory()) to
      dynamically add to, and delete from, the list.
      
      The current ACPI I/O accessing methods - acpi_read() and acpi_write() -
      end up calling ioremap() when accessing MMIO.  This prevents use of these
      methods within interrupt context (IRQ and/or NMI), since ioremap() may
      block to allocate memory.  Maintaining a list of MMIO remappings enables
      accesses to such areas from within interrupt context provided they have
      been pre-mapped.
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      620242ae
    • M
      ACPI: Fix ioremap size for MMIO reads and writes · b3ba1efe
      Myron Stowe 提交于
      The size used for I/O remapping MMIO read and write accesses has not
      accounted for the basis of ACPI's Generic Address Structure (GAS)
      'Register Bit Width' field which is bits, not bytes.  This patch
      adjusts the ioremap() 'size' argument accordingly.
      
      ACPI "Generic Register" reference:
        ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
        Structure".
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b3ba1efe
  8. 20 10月, 2010 1 次提交
  9. 16 10月, 2010 1 次提交
    • L
      ACPI: add FW_BUG to OSI(Linux) message · 3af283e1
      Len Brown 提交于
      Linux-2.6.22 initiated a dmesg complaint when it saw BIOS that invoked
      OSI(Linux).  Linux-2.6.23 continued that complaint and started our
      policy of ignoring the bogus BIOS request.
      
      Past-time for Linux to label that complaint with FW_BUG.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      3af283e1
  10. 01 10月, 2010 3 次提交
  11. 15 8月, 2010 1 次提交
  12. 13 7月, 2010 1 次提交
    • R
      ACPI / ACPICA: Do not execute _PRW methods during initialization · 9874647b
      Rafael J. Wysocki 提交于
      Currently, during initialization ACPICA walks the entire ACPI
      namespace in search of any device objects with assciated _PRW
      methods.  All of the _PRW methods found are executed in the process
      to extract the GPE information returned by them, so that the GPEs in
      question can be marked as "able to wakeup" (more precisely, the
      ACPI_GPE_CAN_WAKE flag is set for them).  The only purpose of this
      exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
      if there are _Lxx/_Exx methods associated with them.  However, it is
      both costly and unnecessary, because the host OS has to execute the
      _PRW methods anyway to check which devices can wake up the system
      from sleep states.  Moreover, it then uses full information
      returned by _PRW, including the GPE information, so it can take care
      of disabling the GPEs if necessary.
      
      Remove the code that walks the namespace and executes _PRW from
      ACPICA and modify comments to reflect that change.  Make
      acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
      so that they don't cause spurious wakeup events to be signaled.
      This not only reduces the complexity of the ACPICA initialization
      code, but in some cases it should reduce the kernel boot time as
      well.
      
      Unfortunately, for this purpose we need a new ACPICA function,
      acpi_gpe_can_wake(), to be called by the host OS in order to disable
      the GPEs that can wake up the system and were previously enabled by
      acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
      should be disabled only once, because the initialization code enables
      it only once, but it may be pointed to by _PRW for multiple devices
      and that's why the additional function is necessary).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      9874647b
  13. 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
  14. 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
  15. 05 4月, 2010 1 次提交
  16. 23 3月, 2010 1 次提交
  17. 16 3月, 2010 1 次提交
  18. 28 1月, 2010 1 次提交
  19. 10 12月, 2009 1 次提交
  20. 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
  21. 24 9月, 2009 1 次提交
  22. 19 9月, 2009 2 次提交
  23. 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
  24. 03 8月, 2009 1 次提交
  25. 24 6月, 2009 1 次提交
  26. 21 4月, 2009 1 次提交