1. 02 6月, 2013 3 次提交
  2. 23 5月, 2013 1 次提交
  3. 22 5月, 2013 1 次提交
    • R
      ACPI / PM: Allow device power states to be used for CONFIG_PM unset · ec4602a9
      Rafael J. Wysocki 提交于
      Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of
      the functions defined in there are replaced with static inline stubs
      if that option is unset.  However, CONFIG_PM means, roughly, "runtime
      PM or suspend/hibernation support" and some of those functions are
      useful regardless of that.  For example, they are used by the ACPI
      fan driver for controlling fans and acpi_device_set_power() is called
      during device removal.  Moreover, device initialization may depend on
      setting device power states properly.
      
      For these reasons, make the routines manipulating ACPI device power
      states defined in drivers/acpi/device_pm.c available for CONFIG_PM
      unset too.
      Reported-by: NZhang Rui <rui.zhang@intel.com>
      Reported-and-tested-by: NMichel Lespinasse <walken@google.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      ec4602a9
  4. 18 5月, 2013 1 次提交
  5. 16 5月, 2013 1 次提交
  6. 14 5月, 2013 2 次提交
  7. 12 5月, 2013 4 次提交
  8. 08 5月, 2013 3 次提交
  9. 02 5月, 2013 1 次提交
  10. 26 4月, 2013 1 次提交
  11. 25 4月, 2013 1 次提交
    • A
      ACPI: video: correct acpi_video_bus_add error processing · 91e13aa3
      Aaron Lu 提交于
      acpi_video_bus_get_devices() may fail due to some video output device
      doesn't have the _ADR method, and in this case, the error processing
      is to simply free the video structure in acpi_video_bus_add(), while
      leaving those already registered video output devices in the wild,
      which means for some video output device, we have already registered
      a backlight interface and installed a notification handler for it.
      So it can happen when user is using this system, on hotkey pressing,
      the notification handler will send a keycode through a non-existing
      input device, causing kernel freeze.
      
      To solve this problem, free all those already registered video output
      devices once something goes wrong in acpi_video_bus_get_devices(), so
      that no wild backlight interfaces and notification handlers exist.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=51731
      Reported-and-tested-by: <i-tek@web.de>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      91e13aa3
  12. 24 4月, 2013 1 次提交
  13. 23 4月, 2013 1 次提交
  14. 22 4月, 2013 1 次提交
  15. 17 4月, 2013 1 次提交
  16. 13 4月, 2013 1 次提交
  17. 12 4月, 2013 11 次提交
  18. 10 4月, 2013 1 次提交
    • A
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro 提交于
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      layout.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d9dda78b
  19. 08 4月, 2013 1 次提交
  20. 03 4月, 2013 2 次提交
    • T
      ACPI / BGRT: Don't let users configure BGRT on non X86 systems · e66cd537
      Tony Luck 提交于
      Fengguang Wu's 0-Day kernel build testing backend found the
      following build error for an allmodconfig build on ia64:
      
         drivers/built-in.o: In function `show_yoffset':
      >> bgrt.c:(.text+0xe5a71): undefined reference to `bgrt_tab'
      >> bgrt.c:(.text+0xe5a91): undefined reference to `bgrt_tab'
         drivers/built-in.o: In function `show_xoffset':
      >> bgrt.c:(.text+0xe5b51): undefined reference to `bgrt_tab'
      >> bgrt.c:(.text+0xe5b71): undefined reference to `bgrt_tab'
         drivers/built-in.o: In function `show_type':
      >> bgrt.c:(.text+0xe5c31): undefined reference to `bgrt_tab'
         drivers/built-in.o:bgrt.c:(.text+0xe5c51): more undefined references to `bgrt_tab' follow
         drivers/built-in.o: In function `bgrt_init':
         bgrt.c:(.init.text+0x8931): undefined reference to `bgrt_image'
         bgrt.c:(.init.text+0x8932): undefined reference to `bgrt_image_size'
         bgrt.c:(.init.text+0x8950): undefined reference to `bgrt_image'
         bgrt.c:(.init.text+0x8960): undefined reference to `bgrt_image_size'
      
      The problem is that all these undefined names are provided by
      arch/x86/platform/efi/efi-bgrt.c - which is obviously not available
      to the ia64 build.
      
      It doesn't seem useful to provide the BGRT support for Itanium
      (many systems are headless and have no graphics at all). So
      just don't let users configure this driver on non-X86 machines.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e66cd537
    • B
      Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus" · b8178f13
      Bjorn Helgaas 提交于
      This reverts commit 8c33f51d.
      
      Conflicts:
      	drivers/acpi/pci_root.c
      
      This commit broke some pre-1.1 PCIe devices by leaving them with
      ASPM enabled.  Previously, we had disabled ASPM on these devices
      because many of them don't implement it correctly (per 149e1637).
      
      Requesting _OSC control early means that aspm_disabled may be set
      before we scan the PCI bus and configure link ASPM state.  But the
      ASPM configuration currently skips the check for pre-PCIe 1.1 devices
      when aspm_disabled is set, like this:
      
          acpi_pci_root_add
            acpi_pci_osc_support
              if (flags != base_flags)
                pcie_no_aspm
                  aspm_disabled = 1
            pci_acpi_scan_root
              ...
                pcie_aspm_init_link_state
                  pcie_aspm_sanity_check
                    if (!aspm_disabled)
                      /* check for pre-PCIe 1.1 device */
      
      Therefore, setting aspm_disabled early means that we leave ASPM enabled
      on these pre-PCIe 1.1 devices, which is a regression for some devices.
      
      The best fix would be to clean up the ASPM init so we can evaluate
      _OSC before scanning the bug (that way boot-time and hot-add discovery
      will work the same), but that requires significant rework.
      
      For now, we'll just revert the _OSC change as the lowest-risk fix.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=55211Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      CC: stable@vger.kernel.org	# v3.8+
      b8178f13
  21. 02 4月, 2013 1 次提交
    • A
      cpuidle / ACPI: recover percpu ACPI processor cstate · 6240a10d
      Alex Shi 提交于
      Commit ac3ebafa "ACPI / idle: remove usage of the statedata"
      changed the percpu processor cstate to a unified cstate in ACPI idle.
      That caused all our NHM boxes to boot hang or panic.
      
      2178751 Task dump for CPU 1:
      	2178752 swapper/1       R  running task     6736     0      1 0x00000000
      	2178753  ffff8801e8029dc8 ffffffff8101cf96 ffff8801e8029e28 ffffffff813d294b
      	2178754  0000000000000f99 0000000000000003 00000000003cf654 0000000025c17d03
      	2178755  ffff8801e8029e38 ffff8801e74fc000 00000002590dc5c4 ffffffff8163cdb0
      	2178756 Call Trace:
      	2178757  [<ffffffff8101cf96>] ? acpi_processor_ffh_cstate_enter+0x2d/0x2f
      	2178758  [<ffffffff813d294b>] acpi_idle_enter_bm+0x1b1/0x236
      	2178759  [<ffffffff8163cdb0>] ? disable_cpuidle+0x10/0x10
      	2178760  [<ffffffff8163cdc2>] cpuidle_enter+0x12/0x14
      	2178761  [<ffffffff8163d286>] cpuidle_wrap_enter+0x2f/0x6d
      	2178762  [<ffffffff8163d2d4>] cpuidle_enter_tk+0x10/0x12
      	2178763  [<ffffffff8163cdd6>] cpuidle_enter_state+0x12/0x3a
      	2178764  [<ffffffff8163d4a7>] cpuidle_idle_call+0xe8/0x161
      	2178765  [<ffffffff81008d99>] cpu_idle+0x5e/0xa4
      	2178766  [<ffffffff8174c6c1>] start_secondary+0x1a9/0x1ad
      	2178767 Task dump for CPU 2:
      
      In fact, the ACPI idle is based on the assumption of difference percpu
      cstate structures that are necessary for the implementation to work
      cprrectly.  A unique acpi_processor_cx is not sifficient by far.
      
      This patch is just a quick fix re-introducing the percpu cstates.
      
      If someone really wants to unify the ACPI cstates, please make sure
      that the whole software infrastructure is changed and take hardware
      as well as many different kinds of BIOS settings into account.
      
      [rjw: Changelog]
      Reported-by: NLKP project <lkp@linux.intel.com>
      Reported-by: NXie ChanglongX <changlongx.xie@intel.com>
      Tested-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NAlex Shi <alex.shi@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6240a10d