RE: ACPICA patch set, release 20080701 & 20080729

[Lin Ming <ming.m.lin@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]

On Fri, 2008-08-08 at 05:50 +0800, Moore, Robert wrote:
> 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

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

> 
> 
> 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
> 
> 
> >-----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 & 20080729
> >
> >
> >
> >
> >>-----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
> >>
> >>>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
> 

[-- Attachment #2: acpica.fixes.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 12082 bytes --]