<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/acpi, branch v3.4.54</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/acpi?h=v3.4.54</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/acpi?h=v3.4.54'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-07-22T01:19:01Z</updated>
<entry>
<title>ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan</title>
<updated>2013-07-22T01:19:01Z</updated>
<author>
<name>Lan Tianyu</name>
<email>tianyu.lan@intel.com</email>
</author>
<published>2013-06-05T02:27:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c31ad446ab92f3da77f4800786302fb479bfcf97'/>
<id>urn:sha1:c31ad446ab92f3da77f4800786302fb479bfcf97</id>
<content type='text'>
commit eff9a4b62b14cf0d9913e3caf1f26f8b7a6105c9 upstream.

HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's
_REG method will access that region.  To allow the CMOS RTC region
handler to be installed before the EC _REG method is first invoked,
add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table.

References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy &lt;public@stefan-nagy.at&gt;
Signed-off-by: Lan Tianyu &lt;tianyu.lan@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6</title>
<updated>2013-06-13T16:45:00Z</updated>
<author>
<name>Ash Willis</name>
<email>ashwillis.kernel@gmail.com</email>
</author>
<published>2013-05-29T01:27:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=06f3ee48d0f0c2a531f7c5ff6355f9ccee32b20d'/>
<id>urn:sha1:06f3ee48d0f0c2a531f7c5ff6355f9ccee32b20d</id>
<content type='text'>
commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream.

This patch addresses kernel bug 56661. BIOS reports an incorrect
backlight value, causing the driver to switch off the backlight
completely during startup. This patch ignores the incorrect value from
BIOS.

References: https://bugzilla.kernel.org/show_bug.cgi?id=56661
Signed-off-by: Ash Willis &lt;ashwillis@programmer.net&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / video: ignore BIOS initial backlight value for HP m4</title>
<updated>2013-06-13T16:44:58Z</updated>
<author>
<name>Alex Hung</name>
<email>alex.hung@canonical.com</email>
</author>
<published>2013-05-28T02:05:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=871483faa88417bcec82ed20050c758cbf65a5ca'/>
<id>urn:sha1:871483faa88417bcec82ed20050c758cbf65a5ca</id>
<content type='text'>
commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream.

On HP m4 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.

References: https://bugs.launchpad.net/bugs/1184501
Signed-off-by: Alex Hung &lt;alex.hung@canonical.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / EC: Restart transaction even when the IBF flag set</title>
<updated>2013-05-19T17:54:49Z</updated>
<author>
<name>Lan Tianyu</name>
<email>tianyu.lan@intel.com</email>
</author>
<published>2013-05-06T03:23:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8401f498590491d3d940d8d78911d554c3e8e215'/>
<id>urn:sha1:8401f498590491d3d940d8d78911d554c3e8e215</id>
<content type='text'>
commit 28fe5c825f8e15744d04c7c1b8df197950923ecd upstream.

The EC driver works abnormally with IBF flag always set.
IBF means "The host has written a byte of data to the command
or data port, but the embedded controller has not yet read it".
If IBF is set in the EC status and not cleared, this will cause
all subsequent EC requests to fail with a timeout error.

Change the EC driver so that it doesn't refuse to restart a
transaction if IBF is set in the status.  Also increase the
number of transaction restarts to 5, as it turns out that 2
is not sufficient in some cases.

This bug happens on several different machines (Asus V1S,
Dell Latitude E6530, Samsung R719, Acer Aspire 5930G,
Sony Vaio SR19VN and others).

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=14733
References: https://bugzilla.kernel.org/show_bug.cgi?id=15560
References: https://bugzilla.kernel.org/show_bug.cgi?id=15946
References: https://bugzilla.kernel.org/show_bug.cgi?id=42945
References: https://bugzilla.kernel.org/show_bug.cgi?id=48221
Signed-off-by: Lan Tianyu &lt;tianyu.lan@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPICA: Fix possible buffer overflow during a field unit read operation</title>
<updated>2013-05-19T17:54:35Z</updated>
<author>
<name>Bob Moore</name>
<email>robert.moore@intel.com</email>
</author>
<published>2013-05-08T04:01:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b03a3c907aa9f1caa0624055374a633a03f8e8b2'/>
<id>urn:sha1:b03a3c907aa9f1caa0624055374a633a03f8e8b2</id>
<content type='text'>
commit 61388f9e5d93053cf399a356414f31f9b4814c6d upstream.

Can only happen under these conditions: 1) The DSDT version is 1,
meaning integers are 32-bits.  2) The field is between 33 and 64
bits long.

It applies cleanly back to ACPICA 20100806+ (Linux v2.6.37+).

Signed-off-by: Bob Moore &lt;robert.moore@intel.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>PCI / ACPI: Don't query OSC support with all possible controls</title>
<updated>2013-05-08T02:51:54Z</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2013-03-28T04:28:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7e99b12d8c65add111c25a17ec49a3a496bdb6b1'/>
<id>urn:sha1:7e99b12d8c65add111c25a17ec49a3a496bdb6b1</id>
<content type='text'>
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 &lt;yinghai@kernel.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI: Add DMI entry for Sony VGN-FW41E_H</title>
<updated>2013-03-03T22:06:44Z</updated>
<author>
<name>Joseph Salisbury</name>
<email>joseph.salisbury@canonical.com</email>
</author>
<published>2013-02-05T00:16:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=427e85ba0d2e3811c130714eea3fec0800ef2fcd'/>
<id>urn:sha1:427e85ba0d2e3811c130714eea3fec0800ef2fcd</id>
<content type='text'>
commit 66f2fda93b67fa744d406e6dcf443f67bac204b6 upstream.

This patch adds a quirk to allow the Sony VGN-FW41E_H to suspend/resume
properly.

References: http://bugs.launchpad.net/bugs/1113547
Signed-off-by: Joseph Salisbury &lt;joseph.salisbury@canonical.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>efi: Make 'efi_enabled' a function to query EFI facilities</title>
<updated>2013-02-14T18:48:53Z</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2012-11-14T09:42:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=739230186fa9d6999f88c53f0cb6d07ed4234fb0'/>
<id>urn:sha1:739230186fa9d6999f88c53f0cb6d07ed4234fb0</id>
<content type='text'>
commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.

Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

    https://bugzilla.kernel.org/show_bug.cgi?id=47121

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Cc: David Airlie &lt;airlied@linux.ie&gt;
Cc: Corentin Chary &lt;corentincj@iksaif.net&gt;
Cc: Matthew Garrett &lt;mjg59@srcf.ucam.org&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Olof Johansson &lt;olof@lixom.net&gt;
Cc: Peter Jones &lt;pjones@redhat.com&gt;
Cc: Colin Ian King &lt;colin.king@canonical.com&gt;
Cc: Steve Langasek &lt;steve.langasek@canonical.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad@kernel.org&gt;
Cc: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / processor: Get power info before updating the C-states</title>
<updated>2013-01-28T04:47:44Z</updated>
<author>
<name>Thomas Schlichter</name>
<email>thomas.schlichter@web.de</email>
</author>
<published>2013-01-18T23:28:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=54980d10c77318729ce2549635e3950fe338ba53'/>
<id>urn:sha1:54980d10c77318729ce2549635e3950fe338ba53</id>
<content type='text'>
commit f427e5f1cf75bba84cccdac1d8a90552d9ae1065 upstream.

acpi_processor_get_power_info() has to be called before
acpi_processor_setup_cpuidle_states() to have the latest
information available. This fixes the missing C-state information
after AC--&gt;DC transition.

Signed-off-by: Thomas Schlichter &lt;thomas.schlichter@web.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / cpuidle: Fix NULL pointer issues when cpuidle is disabled</title>
<updated>2013-01-28T04:47:44Z</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2013-01-16T22:40:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b8b02d1a89f6f0598d815476acce249a4b891020'/>
<id>urn:sha1:b8b02d1a89f6f0598d815476acce249a4b891020</id>
<content type='text'>
commit b88a634a903d9670aa5f2f785aa890628ce0dece upstream.

If cpuidle is disabled, that means that:

	per_cpu(acpi_cpuidle_device, pr-&gt;id)

is set to NULL as the acpi_processor_power_init ends up failing at

	 retval = cpuidle_register_driver(&amp;acpi_idle_driver)

(in acpi_processor_power_init) and never sets the per_cpu idle
device.  So when acpi_processor_hotplug on CPU online notification
tries to reference said device it crashes:

cpu 3 spinlock event irq 62
BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
IP: [&lt;ffffffff81381013&gt;] acpi_processor_setup_cpuidle_cx+0x3f/0x105
PGD a259b067 PUD ab38b067 PMD 0
Oops: 0002 [#1] SMP
odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf
CPU 1
Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680)
RIP: e030:[&lt;ffffffff81381013&gt;]  [&lt;ffffffff81381013&gt;] acpi_processor_setup_cpuidle_cx+0x3f/0x105
RSP: e02b:ffff88001742dca8  EFLAGS: 00010202
RAX: 0000000000010be9 RBX: ffff8800a0a61800 RCX: ffff880105380000
RDX: 0000000000000003 RSI: 0000000000000200 RDI: ffff8800a0a61800
RBP: ffff88001742dce8 R08: ffffffff81812360 R09: 0000000000000200
R10: aaaaaaaaaaaaaaaa R11: 0000000000000001 R12: ffff8800a0a61800
R13: 00000000ffffff01 R14: 0000000000000000 R15: ffffffff81a907a0
FS:  00007fd6942f7700(0000) GS:ffff880105280000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 00000000a6773000 CR4: 0000000000042660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process bash (pid: 3047, threadinfo ffff88001742c000, task ffff880017944000)
Stack:
 0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800
 0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0
 ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336
Call Trace:
 [&lt;ffffffff813815b1&gt;] acpi_processor_hotplug+0x7c/0x9f
 [&lt;ffffffff810ae336&gt;] ? schedule_delayed_work_on+0x16/0x20
 [&lt;ffffffff8137ee8f&gt;] acpi_cpu_soft_notify+0x90/0xca
 [&lt;ffffffff8166023d&gt;] notifier_call_chain+0x4d/0x70
 [&lt;ffffffff810bc369&gt;] __raw_notifier_call_chain+0x9/0x10
 [&lt;ffffffff81094a4b&gt;] __cpu_notify+0x1b/0x30
 [&lt;ffffffff81652cf7&gt;] _cpu_up+0x103/0x14b
 [&lt;ffffffff81652e18&gt;] cpu_up+0xd9/0xec
 [&lt;ffffffff8164a254&gt;] store_online+0x94/0xd0
 [&lt;ffffffff814122fb&gt;] dev_attr_store+0x1b/0x20
 [&lt;ffffffff81216404&gt;] sysfs_write_file+0xf4/0x170

This patch fixes it.

Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
