ACPICA patch set, release 20080701 & 20080729
Hi, Andi
ACPICA release 20080701 & 20080729 patch set for linux attached. I generated this patch set on top of Linus tree.
To apply,
#git-pull linus tree
#git-am R07_29_08.mbox
We now have gaps of 2 release, 20080701 & 20080729, between standard acpica and linux acpica.
Would you please apply this patch set for 2.6.27-rc2?
---
ACPICA: Cleanup macro definition file
ACPICA: Copy dynamically loaded tables to local buffer
ACPICA: Fix warning for 64-bit build
ACPICA: Add check for invalid handle in acpi_get_object_info
ACPICA: Fix memory leak when deleting thermal/processor objects
ACPICA: Allow same ACPI table to be loaded/unloaded more than once
ACPICA: Fix possible memory leak in Unload() operator
ACPICA: Return method arg count from acpi_get_object_info
ACPICA: Fix wrong resource descriptor length for 64-bit build
ACPICA: Fix table compare code, length then data
ACPICA: Update version to 20080701
ACPICA: Return status from global init function
ACPICA: Add function to decode reference obj types to strings
ACPICA: Improve object conversion error messages
ACPICA: x2APIC support: changes for MADT and SRAT ACPI tables
ACPICA: Add function to dereference returned reference objects
ACPICA: Additional error checking for pathname utilities
ACPICA: Update version to 20080729
Thanks,
Lin Ming
Quoted 17 lines
-----Original Message-----
From: Lin, Ming M
Sent: Monday, August 04, 2008 10:16 AM
To: Kleen, Andi; Moore, Robert
Cc: linux-acpi
Subject: ACPICA patch set, release 20080701 & 20080729Hi, Andi
ACPICA release 20080701 & 20080729 patch set for linux attached. I generated this patch set on top of Linus tree.
To apply,
Quoted 7 lines
#git-pull linus tree
#git-am R07_29_08.mboxWe now have gaps of 2 release, 20080701 & 20080729, between standard acpica and linux acpica.
Would you please apply this patch set for 2.6.27-rc2?
Does this one actually apply? The last one didn't.
And it's far too late for feature patches at this point. Can you extract only the bug fixes and non intrusive cleanups?
-Andi
Quoted 2 lines
And it's far too late for feature patches at this point. Can you extract only the bug fixes and non intrusive cleanups?
What does this mean exactly?
Bob
Quoted 38 lines
-----Original Message-----
From: Kleen, Andi
Sent: Thursday, August 07, 2008 2:10 PM
To: Lin, Ming M; Moore, Robert
Cc: linux-acpi
Subject: RE: ACPICA patch set, release 20080701 & 20080729Quoted 14 lines
-----Original Message-----
From: Lin, Ming M
Sent: Monday, August 04, 2008 10:16 AM
To: Kleen, Andi; Moore, Robert
Cc: linux-acpi
Subject: ACPICA patch set, release 20080701 & 20080729Hi, Andi
ACPICA release 20080701 & 20080729 patch set for linux attached. I generated this patch set on top of Linus tree.
To apply,
Quoted 7 lines
#git-pull linus tree
#git-am R07_29_08.mboxWe now have gaps of 2 release, 20080701 & 20080729, between standard acpica and linux acpica.
Would you please apply this patch set for 2.6.27-rc2?
Does this one actually apply? The last one didn't.
And it's far too late for feature patches at this point. Can you extract only the bug fixes and non intrusive cleanups?
-Andi
Quoted 10 lines
-----Original Message-----
From: Moore, Robert
Sent: Thursday, August 07, 2008 11:31 PM
To: Kleen, Andi; Lin, Ming M
Cc: 'linux-acpi'; Brown, Len
Subject: RE: ACPICA patch set, release 20080701 & 20080729
Quoted 4 lines
Quoted 2 lines
And it's far too late for feature patches at this point. Can you extract only the bug fixes and non intrusive cleanups?
What does this mean exactly?
The Linux kernel has this concept of merging windows. After a major release
there is a 2 week merging window where all the features go in. The merge window closes with -rc1. After -rc1 some features can still go in, but in
general larger merges are frowned upon (as in Linus often yells at the submitter) The focus is definitely on bug fixes post -rc1. Also there seem to be unfortunately quite a lot of ACPI regressions this cycle,
so I have to be especially conservative.
A full 2 cycle ACPICA merge would be likely too much
of a merge. Also we need some testing time for major ACPICA changes in -mm/linux-next anyways.
I'm open for relatively clear bug fixes and unlikely to break anything cleanups though to push in for .27. E.g. the pathname fixes would be obvious candidates. Since you know the various patches better than me it makes sense for you to preselect.
I can pull full ACPICA into the test tree of course (assuming it applies). Will do that tomorrow. But test is beyond .27.
-Andi
Here's the patchlist:
ACPICA: Cleanup macro definition file
ACPICA: Copy dynamically loaded tables to local buffer
ACPICA: Fix warning for 64-bit build
ACPICA: Add check for invalid handle in acpi_get_object_info
ACPICA: Fix memory leak when deleting thermal/processor objects
ACPICA: Allow same ACPI table to be loaded/unloaded more than once
ACPICA: Fix possible memory leak in Unload() operator
ACPICA: Return method arg count from acpi_get_object_info
ACPICA: Fix wrong resource descriptor length for 64-bit build
ACPICA: Fix table compare code, length then data
ACPICA: Update version to 20080701
ACPICA: Return status from global init function
ACPICA: Add function to decode reference obj types to strings
ACPICA: Improve object conversion error messages
ACPICA: x2APIC support: changes for MADT and SRAT ACPI tables
ACPICA: Add function to dereference returned reference objects
ACPICA: Additional error checking for pathname utilities
ACPICA: Update version to 20080729
Most of these are bug fixes, new stuff would be the following:
ACPICA: Cleanup macro definition file
ACPICA: Return method arg count from acpi_get_object_info
ACPICA: Add function to decode reference obj types to strings
ACPICA: Improve object conversion error messages
ACPICA: x2APIC support: changes for MADT and SRAT ACPI tables
Leaving these as the bug fixes that should be integrated:
ACPICA: Copy dynamically loaded tables to local buffer
ACPICA: Fix warning for 64-bit build
ACPICA: Add check for invalid handle in acpi_get_object_info
ACPICA: Fix memory leak when deleting thermal/processor objects
ACPICA: Allow same ACPI table to be loaded/unloaded more than once
ACPICA: Fix possible memory leak in Unload() operator
ACPICA: Fix wrong resource descriptor length for 64-bit build
ACPICA: Fix table compare code, length then data
ACPICA: Return status from global init function
ACPICA: Add function to dereference returned reference objects
ACPICA: Additional error checking for pathname utilities
I'm not sure what you should do with the version numbers, I don't think you should advertise a certain version of ACPICA until it has been *fully* integrated.
ACPICA: Update version to 20080701
ACPICA: Update version to 20080729
Quoted 17 lines
-----Original Message-----
From: Kleen, Andi
Sent: Thursday, August 07, 2008 2:43 PM
To: Moore, Robert; Lin, Ming M
Cc: 'linux-acpi'; Brown, Len
Subject: RE: ACPICA patch set, release 20080701 & 20080729Quoted 7 lines
-----Original Message-----
From: Moore, Robert
Sent: Thursday, August 07, 2008 11:31 PM
To: Kleen, Andi; Lin, Ming M
Cc: 'linux-acpi'; Brown, Len
Subject: RE: ACPICA patch set, release 20080701 & 20080729
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
And it's far too late for feature patches at this point. Can you extract only the bug fixes and non intrusive cleanups?
What does this mean exactly?
The Linux kernel has this concept of merging windows. After a major
release
Quoted 1 line
there is a 2 week merging window where all the features go in. The
merge
Quoted 1 line
window closes with -rc1. After -rc1 some features can still go in, but
in
Quoted 3 lines
general larger merges are frowned upon (as in Linus often yells at the submitter) The focus is definitely on bug fixes post -rc1. Also there seem to be unfortunately quite a lot of ACPI regressions this
cycle,
Quoted 15 lines
so I have to be especially conservative.
A full 2 cycle ACPICA merge would be likely too much
of a merge. Also we need some testing time for major ACPICA changes in -mm/linux-next anyways.I'm open for relatively clear bug fixes and unlikely to break anything cleanups though to push in for .27. E.g. the pathname fixes would be obvious candidates. Since you know the various patches better than me it makes sense for you to preselect.
I can pull full ACPICA into the test tree of course (assuming it applies). Will do that tomorrow. But test is beyond .27.
-Andi
Quoted 33 lines · Robert
Here's the patchlist:
ACPICA: Cleanup macro definition file
ACPICA: Copy dynamically loaded tables to local buffer
ACPICA: Fix warning for 64-bit build
ACPICA: Add check for invalid handle inacpi_get_object_info
ACPICA: Fix memory leak when deleting thermal/processor objects
ACPICA: Allow same ACPI table to be loaded/unloaded more than once
ACPICA: Fix possible memory leak inUnload()operator
ACPICA: Return method arg count fromacpi_get_object_info
ACPICA: Fix wrong resource descriptor length for 64-bit build
ACPICA: Fix table compare code, length then data
ACPICA: Update version to 20080701
ACPICA: Return status from global init function
ACPICA: Add function to decode reference obj types to strings
ACPICA: Improve object conversion error messages
ACPICA: x2APIC support: changes for MADT and SRAT ACPI tables
ACPICA: Add function to dereference returned reference objects
ACPICA: Additional error checking for pathname utilities
ACPICA: Update version to 20080729Most of these are bug fixes, new stuff would be the following:
ACPICA: Cleanup macro definition file
ACPICA: Return method arg count fromacpi_get_object_info
ACPICA: Add function to decode reference obj types to strings
ACPICA: Improve object conversion error messages
ACPICA: x2APIC support: changes for MADT and SRAT ACPI tablesLeaving these as the bug fixes that should be integrated:
Quoted 11 lines
ACPICA: Copy dynamically loaded tables to local buffer
ACPICA: Fix warning for 64-bit build
ACPICA: Add check for invalid handle inacpi_get_object_info
ACPICA: Fix memory leak when deleting thermal/processor objects
ACPICA: Allow same ACPI table to be loaded/unloaded more than once
ACPICA: Fix possible memory leak inUnload()operator
ACPICA: Fix wrong resource descriptor length for 64-bit build
ACPICA: Fix table compare code, length then data
ACPICA: Return status from global init function
ACPICA: Add function to dereference returned reference objects
ACPICA: Additional error checking for pathname utilities
Andi,
The attachment is the bug fixes as Bob listed above. It can be applied to your linux-acpi-2.6 tree(test branch).
Lin Ming
Quoted 58 lines
I'm not sure what you should do with the version numbers, I don't think you should advertise a certain version of ACPICA until it has been *fully* integrated.
ACPICA: Update version to 20080701
ACPICA: Update version to 20080729Quoted 17 lines
-----Original Message-----
From: Kleen, Andi
Sent: Thursday, August 07, 2008 2:43 PM
To: Moore, Robert; Lin, Ming M
Cc: 'linux-acpi'; Brown, Len
Subject: RE: ACPICA patch set, release 20080701 & 20080729Quoted 7 lines
-----Original Message-----
From: Moore, Robert
Sent: Thursday, August 07, 2008 11:31 PM
To: Kleen, Andi; Lin, Ming M
Cc: 'linux-acpi'; Brown, Len
Subject: RE: ACPICA patch set, release 20080701 & 20080729Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
And it's far too late for feature patches at this point. Can you extract only the bug fixes and non intrusive cleanups?
What does this mean exactly?
The Linux kernel has this concept of merging windows. After a major
release
Quoted 1 line
there is a 2 week merging window where all the features go in. The
merge
Quoted 1 line
window closes with -rc1. After -rc1 some features can still go in, but
in
Quoted 3 lines
general larger merges are frowned upon (as in Linus often yells at the submitter) The focus is definitely on bug fixes post -rc1. Also there seem to be unfortunately quite a lot of ACPI regressions this
cycle,
Quoted 15 lines
so I have to be especially conservative.
A full 2 cycle ACPICA merge would be likely too much
of a merge. Also we need some testing time for major ACPICA changes in -mm/linux-next anyways.I'm open for relatively clear bug fixes and unlikely to break anything cleanups though to push in for .27. E.g. the pathname fixes would be obvious candidates. Since you know the various patches better than me it makes sense for you to preselect.
I can pull full ACPICA into the test tree of course (assuming it applies). Will do that tomorrow. But test is beyond .27.
-Andi