<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/acpi, branch v3.4.73</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>ACPICA: Fix for a Store-&gt;ArgX when ArgX contains a reference to a field.</title>
<updated>2013-11-29T18:50:31+00:00</updated>
<author>
<name>Bob Moore</name>
<email>robert.moore@intel.com</email>
</author>
<published>2013-09-06T06:27:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8e5931c319674b15847999e79f90e763f32af663'/>
<id>8e5931c319674b15847999e79f90e763f32af663</id>
<content type='text'>
commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.

This change fixes a problem where a Store operation to an ArgX object
that contained a reference to a field object did not complete the
automatic dereference and then write to the actual field object.
Instead, the object type of the field object was inadvertently changed
to match the type of the source operand. The new behavior will actually
write to the field object (buffer field or field unit), thus matching
the correct ACPI-defined behavior.

Signed-off-by: Bob Moore &lt;robert.moore@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.

This change fixes a problem where a Store operation to an ArgX object
that contained a reference to a field object did not complete the
automatic dereference and then write to the actual field object.
Instead, the object type of the field object was inadvertently changed
to match the type of the source operand. The new behavior will actually
write to the field object (buffer field or field unit), thus matching
the correct ACPI-defined behavior.

Signed-off-by: Bob Moore &lt;robert.moore@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPICA: Return error if DerefOf resolves to a null package element.</title>
<updated>2013-11-29T18:50:31+00:00</updated>
<author>
<name>Bob Moore</name>
<email>robert.moore@intel.com</email>
</author>
<published>2013-08-08T07:29:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f9a3a293af3ca3cec5240f0c479f0bed84f195cc'/>
<id>f9a3a293af3ca3cec5240f0c479f0bed84f195cc</id>
<content type='text'>
commit a50abf4842dd7d603a2ad6dcc7f1467fd2a66f03 upstream.

Disallow the dereference of a reference (via index) to an uninitialized
package element. Provides compatibility with other ACPI
implementations. ACPICA BZ 1003.

References: https://bugs.acpica.org/show_bug.cgi?id=431
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a50abf4842dd7d603a2ad6dcc7f1467fd2a66f03 upstream.

Disallow the dereference of a reference (via index) to an uninitialized
package element. Provides compatibility with other ACPI
implementations. ACPICA BZ 1003.

References: https://bugs.acpica.org/show_bug.cgi?id=431
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs.</title>
<updated>2013-11-29T18:50:31+00:00</updated>
<author>
<name>Bob Moore</name>
<email>robert.moore@intel.com</email>
</author>
<published>2013-08-08T07:29:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=71a28e49b6566e92f157c871ce50a9613c682caa'/>
<id>71a28e49b6566e92f157c871ce50a9613c682caa</id>
<content type='text'>
commit 63660e05ec719613b518547b40a1c501c10f0bc4 upstream.

Previously, references to these objects were resolved only to the actual
FieldUnit or BufferField object. The correct behavior is to resolve these
references to an actual value.
The problem is that DerefOf did not resolve these objects to actual
values.  An "Integer" object is simple, return the value.  But a field in
an operation region will require a read operation.  For a BufferField, the
appropriate data must be extracted from the parent buffer.

NOTE: It appears that this issues is present in Windows7 but not
Windows8.

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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 63660e05ec719613b518547b40a1c501c10f0bc4 upstream.

Previously, references to these objects were resolved only to the actual
FieldUnit or BufferField object. The correct behavior is to resolve these
references to an actual value.
The problem is that DerefOf did not resolve these objects to actual
values.  An "Integer" object is simple, return the value.  But a field in
an operation region will require a read operation.  For a BufferField, the
appropriate data must be extracted from the parent buffer.

NOTE: It appears that this issues is present in Windows7 but not
Windows8.

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;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPICA: Interpreter: Fix Store() when implicit conversion is not possible.</title>
<updated>2013-11-29T18:50:31+00:00</updated>
<author>
<name>Bob Moore</name>
<email>robert.moore@intel.com</email>
</author>
<published>2012-12-31T00:11:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b6af75b221f4a998dbbf9297fa3ac591974e70ab'/>
<id>b6af75b221f4a998dbbf9297fa3ac591974e70ab</id>
<content type='text'>
commit 3f654bad3257427bea7ba1c4d43a23d99a03622b upstream.

For the cases such as a store of a string to an existing package
object, implement the store as a CopyObject().
This is a small departure from the ACPI specification which states
that the control method should be aborted in this case. However,
ASLTS suite depends on this behavior.

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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3f654bad3257427bea7ba1c4d43a23d99a03622b upstream.

For the cases such as a store of a string to an existing package
object, implement the store as a CopyObject().
This is a small departure from the ACPI specification which states
that the control method should be aborted in this case. However,
ASLTS suite depends on this behavior.

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;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()</title>
<updated>2013-10-13T22:42:49+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2013-09-13T05:13:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b55ef2eddc365446b824aa9d457dd9daf4d4d4be'/>
<id>b55ef2eddc365446b824aa9d457dd9daf4d4d4be</id>
<content type='text'>
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:
 &lt;IRQ&gt;  [&lt;ffffffff814c4a1e&gt;] dump_stack+0x19/0x1b
 [&lt;ffffffff814bfbab&gt;] __schedule_bug+0x46/0x54
 [&lt;ffffffff814c73e0&gt;] __schedule+0x83/0x59c
 [&lt;ffffffff81058853&gt;] __cond_resched+0x22/0x2d
 [&lt;ffffffff814c794b&gt;] _cond_resched+0x14/0x1d
 [&lt;ffffffff814c6d82&gt;] mutex_lock+0x11/0x32
 [&lt;ffffffff8101e1e9&gt;] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
 [&lt;ffffffffa09e3f9c&gt;] ipmi_msg_handler+0x23/0x166 [ipmi_si]
 [&lt;ffffffff812bf6e4&gt;] deliver_response+0x55/0x5a
 [&lt;ffffffff812c0fd4&gt;] handle_new_recv_msgs+0xb67/0xc65
 [&lt;ffffffff81007ad1&gt;] ? read_tsc+0x9/0x19
 [&lt;ffffffff814c8620&gt;] ? _raw_spin_lock_irq+0xa/0xc
 [&lt;ffffffffa09e1128&gt;] 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} -&gt; {IN-SOFTIRQ-W} usage.
 ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&amp;ipmi_device-&gt;tx_msg_lock){+.?...}, at: [&lt;ffffffff81337a27&gt;] ipmi_msg_handler+0x71/0x126
 {SOFTIRQ-ON-W} state was registered at:
   [&lt;ffffffff810ba11c&gt;] __lock_acquire+0x63c/0x1570
   [&lt;ffffffff810bb0f4&gt;] lock_acquire+0xa4/0x120
   [&lt;ffffffff815581cc&gt;] __mutex_lock_common+0x4c/0x400
   [&lt;ffffffff815586ea&gt;] mutex_lock_nested+0x4a/0x60
   [&lt;ffffffff8133789d&gt;] acpi_ipmi_space_handler+0x11b/0x234
   [&lt;ffffffff81321c62&gt;] 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: Tony Camuso &lt;tcamuso@redhat.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Reviewed-by: Huang Ying &lt;ying.huang@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: Jonghwan Choi &lt;jhbird.choi@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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:
 &lt;IRQ&gt;  [&lt;ffffffff814c4a1e&gt;] dump_stack+0x19/0x1b
 [&lt;ffffffff814bfbab&gt;] __schedule_bug+0x46/0x54
 [&lt;ffffffff814c73e0&gt;] __schedule+0x83/0x59c
 [&lt;ffffffff81058853&gt;] __cond_resched+0x22/0x2d
 [&lt;ffffffff814c794b&gt;] _cond_resched+0x14/0x1d
 [&lt;ffffffff814c6d82&gt;] mutex_lock+0x11/0x32
 [&lt;ffffffff8101e1e9&gt;] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
 [&lt;ffffffffa09e3f9c&gt;] ipmi_msg_handler+0x23/0x166 [ipmi_si]
 [&lt;ffffffff812bf6e4&gt;] deliver_response+0x55/0x5a
 [&lt;ffffffff812c0fd4&gt;] handle_new_recv_msgs+0xb67/0xc65
 [&lt;ffffffff81007ad1&gt;] ? read_tsc+0x9/0x19
 [&lt;ffffffff814c8620&gt;] ? _raw_spin_lock_irq+0xa/0xc
 [&lt;ffffffffa09e1128&gt;] 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} -&gt; {IN-SOFTIRQ-W} usage.
 ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
  (&amp;ipmi_device-&gt;tx_msg_lock){+.?...}, at: [&lt;ffffffff81337a27&gt;] ipmi_msg_handler+0x71/0x126
 {SOFTIRQ-ON-W} state was registered at:
   [&lt;ffffffff810ba11c&gt;] __lock_acquire+0x63c/0x1570
   [&lt;ffffffff810bb0f4&gt;] lock_acquire+0xa4/0x120
   [&lt;ffffffff815581cc&gt;] __mutex_lock_common+0x4c/0x400
   [&lt;ffffffff815586ea&gt;] mutex_lock_nested+0x4a/0x60
   [&lt;ffffffff8133789d&gt;] acpi_ipmi_space_handler+0x11b/0x234
   [&lt;ffffffff81321c62&gt;] 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: Tony Camuso &lt;tcamuso@redhat.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Reviewed-by: Huang Ying &lt;ying.huang@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: Jonghwan Choi &lt;jhbird.choi@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT</title>
<updated>2013-09-08T04:58:15+00:00</updated>
<author>
<name>Lan Tianyu</name>
<email>tianyu.lan@intel.com</email>
</author>
<published>2013-08-26T02:19:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3f661fbf82b3751be0875ed0993d4c29f8268186'/>
<id>3f661fbf82b3751be0875ed0993d4c29f8268186</id>
<content type='text'>
commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports.  The DSDT provides the correct information instead.

For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
Reported-and-tested-by: Daniele Esposti &lt;expo@expobrain.net&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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports.  The DSDT provides the correct information instead.

For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
Reported-and-tested-by: Daniele Esposti &lt;expo@expobrain.net&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;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / battery: Fix parsing _BIX return value</title>
<updated>2013-08-11T22:38:42+00:00</updated>
<author>
<name>Lan Tianyu</name>
<email>tianyu.lan@intel.com</email>
</author>
<published>2013-07-30T12:00:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ee9ef037ac99b542df34848fca2c9765910535e6'/>
<id>ee9ef037ac99b542df34848fca2c9765910535e6</id>
<content type='text'>
commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
of that package should be "Revision".  However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member.  This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: Jan Hoffmann &lt;jan.christian.hoffmann@gmail.com&gt;
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
of that package should be "Revision".  However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member.  This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: Jan Hoffmann &lt;jan.christian.hoffmann@gmail.com&gt;
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / memhotplug: Fix a stale pointer in error path</title>
<updated>2013-08-04T08:25:55+00:00</updated>
<author>
<name>Toshi Kani</name>
<email>toshi.kani@hp.com</email>
</author>
<published>2013-07-10T16:47:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5201cbf11ac566b2eee6eebf334f71ecec3e1724'/>
<id>5201cbf11ac566b2eee6eebf334f71ecec3e1724</id>
<content type='text'>
commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.

device-&gt;driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().

The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory.  A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.

Signed-off-by: Toshi Kani &lt;toshi.kani@hp.com&gt;
Reviewed-by: Yasuaki Ishimatsu &lt;isimatu.yasuaki@jp.fujitsu.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.

device-&gt;driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().

The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory.  A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.

Signed-off-by: Toshi Kani &lt;toshi.kani@hp.com&gt;
Reviewed-by: Yasuaki Ishimatsu &lt;isimatu.yasuaki@jp.fujitsu.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;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan</title>
<updated>2013-07-22T01:19:01+00:00</updated>
<author>
<name>Lan Tianyu</name>
<email>tianyu.lan@intel.com</email>
</author>
<published>2013-06-05T02:27:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c31ad446ab92f3da77f4800786302fb479bfcf97'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6</title>
<updated>2013-06-13T16:45:00+00:00</updated>
<author>
<name>Ash Willis</name>
<email>ashwillis.kernel@gmail.com</email>
</author>
<published>2013-05-29T01:27:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=06f3ee48d0f0c2a531f7c5ff6355f9ccee32b20d'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;

</pre>
</div>
</content>
</entry>
</feed>
