1. 07 4月, 2009 1 次提交
    • L
      hwmon: Add Asus ATK0110 support · 2c03d07a
      Luca Tettamanti 提交于
      Asus boards have an ACPI interface for interacting with the hwmon (fan,
      temperatures, voltages) subsystem; this driver exposes the relevant
      information via the standard sysfs interface.
      
      There are two different ACPI interfaces:
      - an old one (based on RVLT/RFAN/RTMP)
      - a new one (GGRP/GITM)
      Both may be present but there a few cases (my board, sigh) where the
      new interface is just an empty stub; the driver defaults to the old one
      when both are present.
      The old interface has received a considerable testing, but I'm still
      awaiting confirmation from my tester that the new one is working as
      expected (hence the debug code is still enabled).
      
      Currently all the attributes are read-only, though a (partial) control
      should be possible with a bit more work.
      Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      2c03d07a
  2. 05 4月, 2009 1 次提交
    • B
      ACPI: support acpi_device_ops .notify methods · 46ec8598
      Bjorn Helgaas 提交于
      This patch adds support for ACPI device driver .notify() methods.  If
      such a method is present, Linux/ACPI installs a handler for device
      notifications (but not for system notifications such as Bus Check,
      Device Check, etc).  When a device notification occurs, Linux/ACPI
      passes it on to the driver's .notify() method.
      
      In most cases, this removes the need for drivers to install their own
      handlers for device-specific notifications.
      
      For fixed hardware devices like some power and sleep buttons, there's
      no notification value because there's no control method to execute a
      Notify opcode.  When a fixed hardware device generates an event, we
      handle it the same as a regular device notification, except we send
      a ACPI_FIXED_HARDWARE_EVENT value.  This is outside the normal 0x0-0xff
      range used by Notify opcodes.
      
      Several drivers install their own handlers for system Bus Check and
      Device Check notifications so they can support hot-plug.  This patch
      doesn't affect that usage.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Reviewed-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      46ec8598
  3. 04 4月, 2009 2 次提交
  4. 28 3月, 2009 7 次提交
  5. 27 3月, 2009 9 次提交
  6. 17 3月, 2009 1 次提交
  7. 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
  8. 07 2月, 2009 1 次提交
  9. 17 1月, 2009 1 次提交
  10. 09 1月, 2009 3 次提交
  11. 06 1月, 2009 1 次提交
  12. 04 1月, 2009 1 次提交
  13. 31 12月, 2008 11 次提交