1. 06 Jun, 2015 1 commit
  2. 17 May, 2015 2 commits
  3. 19 Apr, 2015 1 commit
  4. 18 Mar, 2015 1 commit
  5. 05 Oct, 2014 1 commit
    • Bob Moore's avatar
      ACPICA: Update to GPIO region handler interface. · a8c91d3c
      Bob Moore authored
      commit 75ec6e55f1384548311a13ce4fcb39c516053314 upstream.
      
      Changes to correct several GPIO issues:
      
      1) The update_rule in a GPIO field definition is now ignored;
      a read-modify-write operation is never performed for GPIO fields.
      (Internally, this means that the field assembly/disassembly
      code is completely bypassed for GPIO.)
      
      2) The Address parameter passed to a GPIO region handler is
      now the bit offset of the field from a previous Connection()
      operator. Thus, it becomes a "Pin Number Index" into the
      Connection() resource descriptor.
      
      3) The bit_width parameter passed to a GPIO region handler is
      now the exact bit width of the GPIO field. Thus, it can be
      interpreted as "number of pins".
      
      Overall, we can now say that the region handler interface
      to GPIO handlers is a raw "bit/pin" addressed interface, not
      a byte-addressed interface like the system_memory handler interface.
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8c91d3c
  6. 17 Sep, 2014 3 commits
  7. 17 Jul, 2014 2 commits
  8. 01 Jul, 2014 2 commits
  9. 07 Jun, 2014 1 commit
  10. 24 Mar, 2014 2 commits
    • Rafael J. Wysocki's avatar
      ACPI / sleep: Add extra checks for HW Reduced ACPI mode sleep states · d4be842b
      Rafael J. Wysocki authored
      commit a4e90bed511220ff601d064c9e5d583e91308f65 upstream.
      
      If the HW Reduced ACPI mode bit is set in the FADT, ACPICA uses
      the optional sleep control and sleep status registers for making
      the system enter sleep states (including S5), so it is not possible
      to use system sleep states or power it off using ACPI if the HW
      Reduced ACPI mode bit is set and those registers are not available.
      
      For this reason, add a new function, acpi_sleep_state_supported(),
      checking if the HW Reduced ACPI mode bit is set and whether or not
      system sleep states are usable in that case in addition to checking
      the return value of acpi_get_sleep_type_data() and make the ACPI
      sleep setup routines use that function to check the availability of
      system sleep states.
      
      Among other things, this prevents the kernel from attempting to
      use ACPI for powering off HW Reduced ACPI systems without the sleep
      control and sleep status registers, because ACPI power off doesn't
      have a chance to work on them.  That allows alternative power off
      mechanisms that may actually work to be used on those systems.  The
      affected machines include Dell Venue 8 Pro, Asus T100TA, Haswell
      Desktop SDP and Ivy Bridge EP Demo depot.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=70931Reported-by: default avatarAdam Williamson <awilliam@redhat.com>
      Tested-by: default avatarAubrey Li <aubrey.li@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4be842b
    • Zhang Rui's avatar
      ACPI / resources: ignore invalid ACPI device resources · 1f7dc3c0
      Zhang Rui authored
      commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream.
      
      ACPI table may export resource entry with 0 length.
      But the current code interprets this kind of resource in a wrong way.
      It will create a resource structure with
      res->end = acpi_resource->start + acpi_resource->len - 1;
      
      This patch fixes a problem on my machine that a platform device fails
      to be created because one of its ACPI IO resource entry (start = 0,
      end = 0, length = 0) is translated into a generic resource with
      start = 0, end = 0xffffffff.
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f7dc3c0
  11. 07 Mar, 2014 3 commits
    • Lan Tianyu's avatar
      ACPI / processor: Rework processor throttling with work_on_cpu() · 44ae49aa
      Lan Tianyu authored
      commit f3ca4164529b875374c410193bbbac0ee960895f upstream.
      
      acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
      sure that the (struct acpi_processor)->acpi_processor_set_throttling()
      callback will run on the right CPU.  However, the function may be
      called from a worker thread already bound to a different CPU in which
      case that won't work.
      
      Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
      instead of abusing set_cpus_allowed_ptr().
      Reported-and-tested-by: default avatarJiri Olsa <jolsa@redhat.com>
      Signed-off-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      [rjw: Changelog]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44ae49aa
    • Hans de Goede's avatar
      ACPI / video: Filter the _BCL table for duplicate brightness values · 3cb947fd
      Hans de Goede authored
      commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream.
      
      Some devices have duplicate entries in there brightness levels table, ie
      on my Dell Latitude E6430 the table looks like this:
      
      [    3.686060] acpi backlight index   0, val 80
      [    3.686095] acpi backlight index   1, val 50
      [    3.686122] acpi backlight index   2, val 5
      [    3.686147] acpi backlight index   3, val 5
      [    3.686172] acpi backlight index   4, val 5
      [    3.686197] acpi backlight index   5, val 5
      [    3.686223] acpi backlight index   6, val 5
      [    3.686248] acpi backlight index   7, val 5
      [    3.686273] acpi backlight index   8, val 6
      [    3.686332] acpi backlight index   9, val 7
      [    3.686356] acpi backlight index  10, val 8
      [    3.686380] acpi backlight index  11, val 9
      etc.
      
      Notice that brightness values 0-5 are all mapped to 5. This means that
      if userspace writes any value between 0 and 5 to the brightness sysfs attribute
      and then reads it, it will always return 0, which is somewhat unexpected.
      
      This is a problem for ie gnome-settings-daemon, which uses read-modify-write
      logic when the users presses the brightness up or down keys. This is done
      this way to take brightness changes from other sources into account.
      
      On this specific laptop what happens once the brightness has been set to 0,
      is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press
      again reads 0, so things get stuck at the lowest brightness setting.
      
      Filtering out the duplicate table entries, makes any write to brightness
      read back as the written value as one would expect, fixing this.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3cb947fd
    • Tomasz Nowicki's avatar
      ACPI / PCI: Fix memory leak in acpi_pci_irq_enable() · 63b5b009
      Tomasz Nowicki authored
      commit b685f3b1744061aa9ad822548ba9c674de5be7c6 upstream.
      
      acpi_pci_link_allocate_irq() can return negative gsi even if
      entry != NULL.  For that case we have a memory leak, so free
      entry before returning from acpi_pci_irq_enable() for gsi < 0.
      Signed-off-by: default avatarTomasz Nowicki <tomasz.nowicki@linaro.org>
      [rjw: Subject and changelog]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63b5b009
  12. 13 Feb, 2014 1 commit
    • Mark Brown's avatar
      ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API · 1ea15c44
      Mark Brown authored
      commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream.
      
      There is currently no facility in ACPI to express the hookup of voltage
      regulators, the expectation is that the regulators that exist in the
      system will be handled transparently by firmware if they need software
      control at all. This means that if for some reason the regulator API is
      enabled on such a system it should assume that any supplies that devices
      need are provided by the system at all relevant times without any software
      intervention.
      
      Tell the regulator core to make this assumption by calling
      regulator_has_full_constraints(). Do this as soon as we know we are using
      ACPI so that the information is available to the regulator core as early
      as possible. This will cause the regulator core to pretend that there is
      an always on regulator supplying any supply that is requested but that has
      not otherwise been mapped which is the behaviour expected on a system with
      ACPI.
      
      Should the ability to specify regulators be added in future revisions of
      ACPI then once we have support for ACPI mappings in the kernel the same
      assumptions will apply. It is also likely that systems will default to a
      mode of operation which does not require any interpretation of these
      mappings in order to be compatible with existing operating system releases
      so it should remain safe to make these assumptions even if the mappings
      exist but are not supported by the kernel.
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ea15c44
  13. 15 Jan, 2014 1 commit
  14. 04 Dec, 2013 1 commit
    • Toshi Kani's avatar
      ACPI / hotplug: Fix conflicted PCI bridge notify handlers · 1ba95636
      Toshi Kani authored
      commit ca499fc87ed945094d952da0eb7eea7dbeb1feec upstream.
      
      The PCI host bridge scan handler installs its own notify handler,
      handle_hotplug_event_root(), by itself.  Nevertheless, the ACPI
      hotplug framework also installs the common notify handler,
      acpi_hotplug_notify_cb(), for PCI root bridges.  This causes
      acpi_hotplug_notify_cb() to call _OST method with unsupported
      error as hotplug.enabled is not set.
      
      To address this issue, introduce hotplug.ignore flag, which
      indicates that the scan handler installs its own notify handler by
      itself.  The ACPI hotplug framework does not install the common
      notify handler when this flag is set.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      [rjw: Changed the name of the new flag]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ba95636
  15. 29 Nov, 2013 8 commits
  16. 13 Oct, 2013 1 commit
    • Lv Zheng's avatar
      ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler() · 2af8997a
      Lv Zheng authored
      commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream.
      
      This patch fixes the issues indicated by the test results that
      ipmi_msg_handler() is invoked in atomic context.
      
      BUG: scheduling while atomic: kipmi0/18933/0x10000100
      Modules linked in: ipmi_si acpi_ipmi ...
      CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G       AW    3.10.0-rc7+ #2
      Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010
       ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8
       ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4
       0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8
      Call Trace:
       <IRQ>  [<ffffffff814c4a1e>] dump_stack+0x19/0x1b
       [<ffffffff814bfbab>] __schedule_bug+0x46/0x54
       [<ffffffff814c73e0>] __schedule+0x83/0x59c
       [<ffffffff81058853>] __cond_resched+0x22/0x2d
       [<ffffffff814c794b>] _cond_resched+0x14/0x1d
       [<ffffffff814c6d82>] mutex_lock+0x11/0x32
       [<ffffffff8101e1e9>] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
       [<ffffffffa09e3f9c>] ipmi_msg_handler+0x23/0x166 [ipmi_si]
       [<ffffffff812bf6e4>] deliver_response+0x55/0x5a
       [<ffffffff812c0fd4>] handle_new_recv_msgs+0xb67/0xc65
       [<ffffffff81007ad1>] ? read_tsc+0x9/0x19
       [<ffffffff814c8620>] ? _raw_spin_lock_irq+0xa/0xc
       [<ffffffffa09e1128>] ipmi_thread+0x5c/0x146 [ipmi_si]
       ...
      
      Also Tony Camuso says:
      
       We were getting occasional "Scheduling while atomic" call traces
       during boot on some systems. Problem was first seen on a Cisco C210
       but we were able to reproduce it on a Cisco c220m3. Setting
       CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
       tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.
      
       =================================
       [ INFO: inconsistent lock state ]
       2.6.32-415.el6.x86_64-debug-splck #1
       ---------------------------------
       inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
       ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
        (&ipmi_device->tx_msg_lock){+.?...}, at: [<ffffffff81337a27>] ipmi_msg_handler+0x71/0x126
       {SOFTIRQ-ON-W} state was registered at:
         [<ffffffff810ba11c>] __lock_acquire+0x63c/0x1570
         [<ffffffff810bb0f4>] lock_acquire+0xa4/0x120
         [<ffffffff815581cc>] __mutex_lock_common+0x4c/0x400
         [<ffffffff815586ea>] mutex_lock_nested+0x4a/0x60
         [<ffffffff8133789d>] acpi_ipmi_space_handler+0x11b/0x234
         [<ffffffff81321c62>] acpi_ev_address_space_dispatch+0x170/0x1be
      
      The fix implemented by this change has been tested by Tony:
      
       Tested the patch in a boot loop with lockdep debug enabled and never
       saw the problem in over 400 reboots.
      Reported-and-tested-by: default avatarTony Camuso <tcamuso@redhat.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Reviewed-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Jonghwan Choi <jhbird.choi@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2af8997a
  17. 27 Sep, 2013 1 commit
  18. 08 Sep, 2013 1 commit
  19. 29 Aug, 2013 2 commits
    • Rafael J. Wysocki's avatar
      ACPI: Try harder to resolve _ADR collisions for bridges · 6e4fdb80
      Rafael J. Wysocki authored
      commit 60f75b8e97daf4a39790a20d962cb861b9220af5 upstream.
      
      In theory, under a given ACPI namespace node there should be only
      one child device object with _ADR whose value matches a given bus
      address exactly.  In practice, however, there are systems in which
      multiple child device objects under a given parent have _ADR matching
      exactly the same address.  In those cases we use _STA to determine
      which of the multiple matching devices is enabled, since some systems
      are known to indicate which ACPI device object to associate with the
      given physical (usually PCI) device this way.
      
      Unfortunately, as it turns out, there are systems in which many
      device objects under the same parent have _ADR matching exactly the
      same bus address and none of them has _STA, in which case they all
      should be regarded as enabled according to the spec.  Still, if
      those device objects are supposed to represent bridges (e.g. this
      is the case for device objects corresponding to PCIe ports), we can
      try harder and skip the ones that have no child device objects in the
      ACPI namespace.  With luck, we can avoid using device objects that we
      are not expected to use this way.
      
      Although this only works for bridges whose children also have ACPI
      namespace representation, it is sufficient to address graphics
      adapter detection issues on some systems, so rework the code finding
      a matching device ACPI handle for a given bus address to implement
      this idea.
      
      Introduce a new function, acpi_find_child(), taking three arguments:
      the ACPI handle of the device's parent, a bus address suitable for
      the device's bus type and a bool indicating if the device is a
      bridge and make it work as outlined above.  Reimplement the function
      currently used for this purpose, acpi_get_child(), as a call to
      acpi_find_child() with the last argument set to 'false' and make
      the PCI subsystem use acpi_find_child() with the bridge information
      passed as the last argument to it.  [Lan Tianyu notices that it is
      not sufficient to use pci_is_bridge() for that, because the device's
      subordinate pointer hasn't been set yet at this point, so use
      hdr_type instead.]
      
      This change fixes a regression introduced inadvertently by commit
      33f767d7 (ACPI: Rework acpi_get_child() to be more efficient) which
      overlooked the fact that for acpi_walk_namespace() "post-order" means
      "after all children have been visited" rather than "on the way back",
      so for device objects without children and for namespace walks of
      depth 1, as in the acpi_get_child() case, the "post-order" callbacks
      ordering is actually the same as the ordering of "pre-order" ones.
      Since that commit changed the namespace walk in acpi_get_child() to
      terminate after finding the first matching object instead of going
      through all of them and returning the last one, it effectively
      changed the result returned by that function in some rare cases and
      that led to problems (the switch from a "pre-order" to a "post-order"
      callback was supposed to prevent that from happening, but it was
      ineffective).
      
      As it turns out, the systems where the change made by commit
      33f767d7 actually matters are those where there are multiple ACPI
      device objects representing the same PCIe port (which effectively
      is a bridge).  Moreover, only one of them, and the one we are
      expected to use, has child device objects in the ACPI namespace,
      so the regression can be addressed as described above.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=60561Reported-by: default avatarPeter Wu <lekensteyn@gmail.com>
      Tested-by: default avatarVladimir Lalov <mail@vlalov.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Peter Wu <lekensteyn@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e4fdb80
    • Jeff Wu's avatar
      ACPI: add _STA evaluation at do_acpi_find_child() · 2ac3b5e4
      Jeff Wu authored
      commit c7d9ca90aa9497f0b6e301ec67c52dd4b57a7852 upstream.
      
      Once do_acpi_find_child() has found the first matching handle, it
      makes the acpi_get_child() loop stop and return that handle.  On some
      platforms, though, there are multiple devices with the same value of
      "_ADR" in the same namespace scope, and if one of them is enabled,
      the others will be disabled.  For example:
      
       Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV0
       Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV1
       Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV2
      
      If DEV0 and DEV1 are disabled and DEV2 is enabled, the handle of DEV2
      should be returned, but actually the function always returns the
      handle of DEV0.
      
      To address that issue, make do_acpi_find_child() evaluate _STA to
      check the device status.  If a matching device object exists, but is
      disabled, acpi_get_child() will continue to walk the namespace in the
      hope of finding an enabled one.  If one is found, its handle will be
      returned, but otherwise the function will return the handle of the
      disabled object found before (in case it is enabled going forward).
      
      [rjw: Changelog]
      Signed-off-by: default avatarJeff Wu <zlinuxkernel@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Peter Wu <lekensteyn@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ac3b5e4
  20. 15 Aug, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Walk physical_node_list under physical_node_lock · b97f921b
      Rafael J. Wysocki authored
      commit 623cf33cb055b1e81fa47e4fc16789b2c129e31e upstream.
      
      The list of physical devices corresponding to an ACPI device
      object is walked by acpi_system_wakeup_device_seq_show() and
      physical_device_enable_wakeup() without taking that object's
      physical_node_lock mutex.  Since each of those functions may be
      run at any time as a result of a user space action, the lack of
      appropriate locking in them may lead to a kernel crash if that
      happens during device hot-add or hot-remove involving the device
      object in question.
      
      Fix the issue by modifying acpi_system_wakeup_device_seq_show() and
      physical_device_enable_wakeup() to use physical_node_lock as
      appropriate.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b97f921b
  21. 12 Aug, 2013 1 commit
  22. 04 Aug, 2013 3 commits