<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/acpi/bus.c, branch linux-2.6.33.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.33.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.33.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2010-01-16T04:05:00Z</updated>
<entry>
<title>ACPI: Advertise to BIOS in _OSC: _OST on _PPC changes</title>
<updated>2010-01-16T04:05:00Z</updated>
<author>
<name>Zhao Yakui</name>
</author>
<published>2010-01-08T13:29:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6a4e2b7503d1f630bface040cf0f5a7aac1fabdb'/>
<id>urn:sha1:6a4e2b7503d1f630bface040cf0f5a7aac1fabdb</id>
<content type='text'>
If the BIOS pokes the system-wide OSC bits to see if Linux
supports evaluating _OST after a _PPC change notification,
answer yes.

Also, fix an oversight where we neglected to set the OSC
bit advertising processor aggregator device support
when acpi-pad is compiled as a module.

Signed-off-by: Zhao Yakui &lt;yakui.zhao@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge branches 'bugzilla-14446', 'bugzilla-14753' and 'bugzilla-14824' into release</title>
<updated>2009-12-24T06:17:01Z</updated>
<author>
<name>Len Brown</name>
</author>
<published>2009-12-24T06:17:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=309ddc53be1766d6ed5411a3dc1782c2040198fa'/>
<id>urn:sha1:309ddc53be1766d6ed5411a3dc1782c2040198fa</id>
<content type='text'>
</content>
</entry>
<entry>
<title>ACPI: fix OSC regression that caused aer and pciehp not to load</title>
<updated>2009-12-23T22:42:07Z</updated>
<author>
<name>Shaohua Li</name>
</author>
<published>2009-12-23T09:04:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9dc130fccb874f2959ef313d7922d306dc6d4f75'/>
<id>urn:sha1:9dc130fccb874f2959ef313d7922d306dc6d4f75</id>
<content type='text'>
Executing _OSC returns a buffer, which has an acpi object in it.
Don't directly returns the buffer, instead, we return the acpi object's
buffer. This fixes a regression since caller of acpi_run_osc expects
an acpi object's buffer returned.

Tested-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Shaohua Li &lt;shaohua.li@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: processor: call _PDC early</title>
<updated>2009-12-22T08:24:08Z</updated>
<author>
<name>Alex Chiang</name>
</author>
<published>2009-12-20T19:19:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=78f1699659963fff97975df44db6d5dbe7218e55'/>
<id>urn:sha1:78f1699659963fff97975df44db6d5dbe7218e55</id>
<content type='text'>
We discovered that at least one machine (HP Envy), methods in the DSDT
attempt to call external methods defined in a dynamically loaded SSDT.

Unfortunately, the DSDT methods we are trying to call are part of the
EC initialization, which happens very early, and the the dynamic SSDT
is only loaded when a processor _PDC method runs much later.

This results in namespace lookup errors for the (as of yet) undefined
methods.

Since Windows doesn't have any issues with this machine, we take it
as a hint that they must be evaluating _PDC much earlier than we are.

Thus, the proper thing for Linux to do should be to match the Windows
implementation more closely.

Provide a mechanism to call _PDC before we enable the EC. Doing so loads
the dynamic tables, and allows the EC to be enabled correctly.

The ACPI processor driver will still evaluate _PDC in its .add() method
to cover the hotplug case.

Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824

Cc: ming.m.lin@intel.com
Signed-off-by: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: Add platform-wide _OSC support.</title>
<updated>2009-12-16T19:05:34Z</updated>
<author>
<name>Shaohua Li</name>
</author>
<published>2009-10-29T03:05:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3563ff964fdc36358cef0330936fdac28e65142a'/>
<id>urn:sha1:3563ff964fdc36358cef0330936fdac28e65142a</id>
<content type='text'>
Signed-off-by: Shaohua Li &lt;shaohua.li@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: Add a generic API for _OSC -v2</title>
<updated>2009-12-16T19:03:30Z</updated>
<author>
<name>Shaohua Li</name>
</author>
<published>2009-10-29T03:04:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=70023de88c58a81a730ab4d13c51a30e537ec76e'/>
<id>urn:sha1:70023de88c58a81a730ab4d13c51a30e537ec76e</id>
<content type='text'>
v2-&gt;v1:
.improve debug info as suggedted by Bjorn,Kenji
.API is using uuid string as suggested by Alexey

Add an API to execute _OSC. A lot of devices can have this method, so add a
generic API.

Signed-off-by: Shaohua Li &lt;shaohua.li@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: add acpi_bus_get_status_handle()</title>
<updated>2009-09-25T18:24:30Z</updated>
<author>
<name>Bjorn Helgaas</name>
</author>
<published>2009-09-21T19:30:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=402ac53614bce0c273c73a80339556bf56dd3d39'/>
<id>urn:sha1:402ac53614bce0c273c73a80339556bf56dd3d39</id>
<content type='text'>
Add acpi_bus_get_status_handle() so we can get the status of a namespace
object before building a struct acpi_device.

This removes a use of "device-&gt;flags.dynamic_status", a cached indicator of
whether _STA exists.  It seems simpler and more reliable to just evaluate
_STA and catch AE_NOT_FOUND errors.

Signed-off-by: Bjorn Helgaas &lt;bjorn.helgaas@hp.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'misc-2.6.32' into release</title>
<updated>2009-09-19T06:14:45Z</updated>
<author>
<name>Len Brown</name>
</author>
<published>2009-09-19T06:14:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d26f0528d588e596955bf296a609afe52eafc099'/>
<id>urn:sha1:d26f0528d588e596955bf296a609afe52eafc099</id>
<content type='text'>
Conflicts:
	drivers/pci/dmar.c

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: linux/acpi.h should not include linux/dmi.h</title>
<updated>2009-09-19T05:33:27Z</updated>
<author>
<name>Len Brown</name>
</author>
<published>2009-07-07T03:40:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eb27cae8adaa658a0bf31631baa1ce29d8183759'/>
<id>urn:sha1:eb27cae8adaa658a0bf31631baa1ce29d8183759</id>
<content type='text'>
users of acpi.h that need dmi.h should include it directly.

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPICA: Fix several acpi_attach_data problems</title>
<updated>2009-08-27T14:17:19Z</updated>
<author>
<name>Bob Moore</name>
</author>
<published>2009-06-29T05:43:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8e4319c425077c4cc540696a5bb6c4d12f017dcd'/>
<id>urn:sha1:8e4319c425077c4cc540696a5bb6c4d12f017dcd</id>
<content type='text'>
Handler was never invoked. Now invoked if/when host node is deleted.
Data object was not automatically deleted when host node was deleted.
Interface to handler had an unused parameter, removed it.
ACPICA BZ 778.

http://acpica.org/bugzilla/show_bug.cgi?id=778

Signed-off-by: Bob Moore &lt;robert.moore@intel.com&gt;
Signed-off-by: Lin Ming &lt;ming.m.lin@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
</feed>
