Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 5月, 2013 1 次提交
    • R
      ACPI / PM: Move processor suspend/resume to syscore_ops · 0a3b15ac
      由 Rafael J. Wysocki 提交于 
      The system suspend routine of the ACPI processor driver saves
the BUS_MASTER_RLD register and its resume routine restores it.
However, there can be only one such register in the system and it
really should be saved after non-boot CPUs have been offlined and
restored before they are put back online during resume.

For this reason, move the saving and restoration of BUS_MASTER_RLD
to syscore suspend and syscore resume, respectively, and drop the no
longer necessary suspend/resume callbacks from the ACPI processor
driver.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0a3b15ac
  3. 08 5月, 2013 3 次提交
  5. 02 5月, 2013 1 次提交
  7. 26 4月, 2013 1 次提交
  9. 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
  11. 24 4月, 2013 1 次提交
  13. 23 4月, 2013 1 次提交
  15. 22 4月, 2013 1 次提交
  17. 17 4月, 2013 1 次提交
  19. 13 4月, 2013 1 次提交
  21. 12 4月, 2013 11 次提交
  23. 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
  25. 08 4月, 2013 1 次提交
  27. 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
  29. 02 4月, 2013 2 次提交
    • 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
    • R
      ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices() · b34bb1ee
      由 Rafael J. Wysocki 提交于 
      The ACPI handle of struct i2c_adapter's dev member should not be
set, because this causes that struct i2c_adapter to be associated
with the ACPI device node corresponding to its parent as the
second "physical_device", which is incorrect (this happens during
the registration of struct i2c_adapter).  Consequently,
acpi_i2c_register_devices() should use the ACPI handle of the
parent of the struct i2c_adapter it is called for rather than the
struct i2c_adapter's ACPI handle (which should be NULL).

Make that happen and modify the i2c-designware-platdrv driver,
which currently is the only driver for ACPI-enumerated I2C
controller chips, not to set the ACPI handle for the
struct i2c_adapter it creates.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
      b34bb1ee
  31. 30 3月, 2013 1 次提交
    • Y
      PCI / ACPI: Don't query OSC support with all possible controls · 545d6e18
      由 Yinghai Lu 提交于 
      Found problem on system that firmware that could handle pci aer.
Firmware get error reporting after pci injecting error, before os boots.
But after os boots, firmware can not get report anymore, even pci=noaer
is passed.

Root cause: BIOS _OSC has problem with query bit checking.
It turns out that BIOS vendor is copying example code from ACPI Spec.
In ACPI Spec 5.0, page 290:

	If (Not(And(CDW1,1))) // Query flag clear?
	{	// Disable GPEs for features granted native control.
		If (And(CTRL,0x01)) // Hot plug control granted?
		{
			Store(0,HPCE) // clear the hot plug SCI enable bit
			Store(1,HPCS) // clear the hot plug SCI status bit
		}
	...
	}

When Query flag is set, And(CDW1,1) will be 1, Not(1) will return 0xfffffffe.
So it will get into code path that should be for control set only.
BIOS acpi code should be changed to "If (LEqual(And(CDW1,1), 0)))"

Current kernel code is using _OSC query to notify firmware about support
from OS and then use _OSC to set control bits.
During query support, current code is using all possible controls.
So will execute code that should be only for control set stage.

That will have problem when pci=noaer or aer firmware_first is used.
As firmware have that control set for os aer already in query support stage,
but later will not os aer handling.

We should avoid passing all possible controls, just use osc_control_set
instead.
That should workaround BIOS bugs with affected systems on the field
as more bios vendors are copying sample code from ACPI spec.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      545d6e18
  33. 27 3月, 2013 3 次提交
  35. 26 3月, 2013 2 次提交
  37. 25 3月, 2013 5 次提交