1. 17 10月, 2012 1 次提交
  2. 09 10月, 2012 1 次提交
  3. 07 10月, 2012 4 次提交
    • L
      ACPI: Add new sysfs interface to export device description · d1efe3c3
      Lance Ortiz 提交于
      Add support to export the device description obtained from the ACPI _STR
      method, if one exists for a device, to user-space via a sysfs interface.
      This new interface provides a standard and platform neutral way for users
      to obtain the description text stored in the ACPI _STR method.  If no
      _STR method exists for the device, no sysfs 'description' file will be
      created.  The 'description' file will be located in the /sys/devices/
      directory using the device's path.
      
      /sys/device/<bus>/<bridge path>/<device path>.../firmware_node/description
      
      Example:
      
      /sys/devices/pci0000:00/0000:00.07.0/0000:0e:00.0/firmware_node/description
      
      It can also be located using the ACPI device path, for example:
      
      /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:13/device:15/description
      /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/ACPI0004:01/ACPI0007:02/description
      
      Execute the 'cat' command on the 'description' file to obtain the
      description string for that device.
      
      This patch also includes documentation describing how the new sysfs
      interface works
      
      Changes from v1-v2 based on comments by Len Brown and Fengguang Wu
      * Removed output "No Description" and leaving a NULL attribute if the
      _STR method failed to evaluate.
      
      * In acpi_device_remove_files() removed the redundent check of
      dev->pnp.str_obj before calling free.  This check triggered a message
      from smatch.
      Signed-off-by: NLance Ortiz <lance.ortiz@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d1efe3c3
    • F
      ACPI: Harden acpi_table_parse_entries() against BIOS bug · 369d913b
      Fenghua Yu 提交于
      Parsing acpi table entries may fall into an infinite loop on a buggy BIOS
      which has entry length=0 in acpi table.
      
      Instead of kernel hang with few failure clue which leads to heavy lifting debug
      effort, this patch hardens kernel boot by booting into non NUMA mode. The debug
      info left in log buffer helps people identify the issue.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      369d913b
    • F
      ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop · 67bfa9b6
      Feng Tang 提交于
      By enlarging the GPE storm threshold back to 20, that laptop's
      EC works fine with interrupt mode instead of polling mode.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=45151Reported-and-Tested-by: NFrancesco <trentini@dei.unipd.it>
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      cc: stable@vger.kernel.org
      67bfa9b6
    • F
      ACPI: EC: Make the GPE storm threshold a module parameter · a520d52e
      Feng Tang 提交于
      The Linux EC driver includes a mechanism to detect GPE storms,
      and switch from interrupt-mode to polling mode.  However, polling
      mode sometimes doesn't work, so the workaround is problematic.
      Also, different systems seem to need the threshold for detecting
      the GPE storm at different levels.
      
      ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and
      was changed to 8 in 2.6.28 commit 06cf7d3c "ACPI: EC: lower interrupt storm
      threshold" to fix kernel bug 11892 by forcing the laptop in that bug to
      work in polling mode. However in bug 45151, it works fine in interrupt
      mode if we lift the threshold back to 20.
      
      This patch makes the threshold a module parameter so that user has a
      flexible option to debug/workaround this issue.
      
      The default is unchanged.
      
      This is also a preparation patch to fix specific systems:
      	https://bugzilla.kernel.org/show_bug.cgi?id=45151Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      cc: stable@vger.kernel.org
      a520d52e
  4. 30 9月, 2012 1 次提交
  5. 25 9月, 2012 8 次提交
  6. 24 9月, 2012 4 次提交
  7. 22 9月, 2012 5 次提交
  8. 21 9月, 2012 11 次提交
  9. 18 9月, 2012 1 次提交
    • D
      cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure · 3d339dcb
      Daniel Lezcano 提交于
      Currently we have the cpuidle_device field in the acpi_processor_power structure.
      This adds a dependency between processor.h and cpuidle.h
      
      Although it is not a real problem, removing this dependency has the benefit of
      separating a bit more the cpuidle code from the rest of the acpi code.
      Also, the compilation should be a bit improved because we do no longer
      include cpuidle.h in processor.h. The preprocessor was generating 30418 loc
      and with this patch it generates 30256 loc for processor_thermal.c, a file
      which is not concerned at all by cpuidle, like processor_perflib.c and
      processor_throttling.c.
      
      That may sound ridiculous, but "small streams make big rivers" :P
      
      This patch moves this field into a static global per cpu variable like what is
      done in the intel_idle driver.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      3d339dcb
  10. 16 9月, 2012 2 次提交
  11. 15 9月, 2012 1 次提交
  12. 14 9月, 2012 1 次提交
    • L
      ACPI / PM: Fix resource_lock dead lock in acpi_power_on_device · 40bf66ec
      Lin Ming 提交于
      Commit 0090def6("ACPI: Add interface to register/unregister device
      to/from power resources") used resource_lock to protect the devices list
      that relies on power resource. It caused a mutex dead lock, as below
      
          acpi_power_on ---> lock resource_lock
            __acpi_power_on
              acpi_power_on_device
                acpi_power_get_inferred_state
                  acpi_power_get_list_state ---> lock resource_lock
      
      This patch adds a new mutex "devices_lock" to protect the devices list
      and calls acpi_power_on_device in acpi_power_on, instead of
      __acpi_power_on, after the resource_lock is released.
      
      [rjw: Changed data type of a boolean variable to bool.]
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      40bf66ec