linux-toradex.git/drivers/acpi, branch v3.9.2

ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip points

2013-05-08T03:33:11+00:00

commit 94a409319561ec1847fd9bf996a2d5843ad00932 upstream.

Commit 4ae46be "Thermal: Introduce thermal_zone_trip_update()"
introduced a regression causing the fan to be always on even when
the system is idle.

My original idea in that commit is that:
 - when the current temperature is above the trip point,
   keep the fan on, even if the temperature is dropping.
 - when the current temperature is below the trip point,
   turn on the fan when the temperature is raising,
   turn off the fan when the temperature is dropping.

But this is what the code actually does:
 - when the current temperature is above the trip point,
   the fan keeps on.
 - when the current temperature is below the trip point,
   the fan is always on because thermal_get_trend()
   in driver/acpi/thermal.c returns THERMAL_TREND_RAISING.
Thus the fan keeps running even if the system is idle.

Fix this in drivers/acpi/thermal.c.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=56591
References: https://bugzilla.kernel.org/show_bug.cgi?id=56601
References: https://bugzilla.kernel.org/show_bug.cgi?id=50041#c45
Signed-off-by: Zhang Rui 
Tested-by: Matthias 
Tested-by: Ville Syrjälä 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: Fix wrong parameter passed to memblock_reserve

2013-05-08T03:33:11+00:00

commit a6432ded299726f123b93d0132fead200551535c upstream.

Commit 53aac44 (ACPI: Store valid ACPI tables passed via early initrd
in reserved memblock areas) introduced acpi_initrd_override() that
passes a wrong value as the second argument to memblock_reserve().

Namely, the second argument of memblock_reserve() is the size of the
region, not the address of the top of it, so make
acpi_initrd_override() pass the size in there as appropriate.

[rjw: Changelog]
Signed-off-by: Wang YanQing 
Acked-by: Yinghai Lu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PCI / ACPI: Don't query OSC support with all possible controls

2013-05-08T03:33:08+00:00

commit 545d6e189a41c94c11f55045a771118eccc9d9eb upstream.

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: Yinghai Lu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'pci-v3.9-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2013-04-06T02:29:36+00:00

Pull PCI fixes from Bjorn Helgaas:
 "PCI updates for v3.9:

  ASPM
      Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"
  kexec
      PCI: Don't try to disable Bus Master on disconnected PCI devices
  Platform ROM images
      PCI: Add PCI ROM helper for platform-provided ROM images
      nouveau: Attempt to use platform-provided ROM image
      radeon: Attempt to use platform-provided ROM image
  Hotplug
      PCI/ACPI: Always resume devices on ACPI wakeup notifications
      PCI/PM: Disable runtime PM of PCIe ports
  EISA
      EISA/PCI: Fix bus res reference
      EISA/PCI: Init EISA early, before PNP"

* tag 'pci-v3.9-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI/PM: Disable runtime PM of PCIe ports
  PCI/ACPI: Always resume devices on ACPI wakeup notifications
  PCI: Don't try to disable Bus Master on disconnected PCI devices
  Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"
  radeon: Attempt to use platform-provided ROM image
  nouveau: Attempt to use platform-provided ROM image
  EISA/PCI: Init EISA early, before PNP
  EISA/PCI: Fix bus res reference
  PCI: Add PCI ROM helper for platform-provided ROM images

ACPI / BGRT: Don't let users configure BGRT on non X86 systems

2013-04-03T11:17:20+00:00

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: Fengguang Wu 
Acked-by: H. Peter Anvin 
Signed-off-by: Tony Luck 
Signed-off-by: Rafael J. Wysocki

Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"

2013-04-03T00:02:40+00:00

This reverts commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6.

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=55211
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
Acked-by: Yinghai Lu 
CC: stable@vger.kernel.org	# v3.8+

cpuidle / ACPI: recover percpu ACPI processor cstate

2013-04-02T13:31:28+00:00

Commit ac3ebafa81af76d6 "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  [] ? acpi_processor_ffh_cstate_enter+0x2d/0x2f
	2178758  [] acpi_idle_enter_bm+0x1b1/0x236
	2178759  [] ? disable_cpuidle+0x10/0x10
	2178760  [] cpuidle_enter+0x12/0x14
	2178761  [] cpuidle_wrap_enter+0x2f/0x6d
	2178762  [] cpuidle_enter_tk+0x10/0x12
	2178763  [] cpuidle_enter_state+0x12/0x3a
	2178764  [] cpuidle_idle_call+0xe8/0x161
	2178765  [] cpu_idle+0x5e/0xa4
	2178766  [] 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: LKP project 
Reported-by: Xie ChanglongX 
Tested-by: Yinghai Lu 
Signed-off-by: Alex Shi 
Signed-off-by: Rafael J. Wysocki

ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices()

2013-04-02T13:30:41+00:00

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: Rafael J. Wysocki 
Reviewed-by: Aaron Lu 
Acked-by: Mika Westerberg 
Acked-by: Wolfram Sang

PCI / ACPI: hold acpi_scan_lock during root bus hotplug

2013-03-26T23:06:07+00:00

During merging the PCI tree with the PM/ACPI tree, Linus noticed
that we don't use the same lock using patten about ACPI PCI root as
acpiphp.

Here apply the same locking patten, and we need to execute
acpi_bus_hot_remove_device() via acpi_os_hotplug_execute()
as it also holds acpi_scan_lock.

[rjw: Changelog]
Reported-by: Linus Torvalds 
Signed-off-by: Yinghai Lu 
No-objection-from: Bjorn Helgaas 
Signed-off-by: Rafael J. Wysocki

ACPI / APEI: fix error status check condition for CPER

2013-03-26T23:05:46+00:00

In Table 18-289, ACPI5.0 SPEC, the error data length in CPER
Generic Error Data Entry can be 0, which means this generic
error data entry can have only one header. So fix the check
conditon for it.

Signed-off-by: Chen Gong 
Reviewed-by: Huang Ying 
Signed-off-by: Rafael J. Wysocki