Age | Commit message (Collapse) | Author |
|
This message happens when the package element list is longer than
the declared length of the package. Changed to an info message
because this condition is not actually an error. It is caused by
the BIOS attempting to truncate the package on the fly by adjusting
the package element count at the start of the package definition.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Fixes a possible memory leak in the interpreter for package
objects if the package initializer list is longer than the
defined size of the package. This apparently can only happen
if the BIOS changes the package size on the fly (seen in a _PSS
object), as both iASL and the other compiler do not allow this.
The interpreter will truncate the package to the defined size
(and issue an error message), but can leave the extra objects
undeleted if they have been pre-created during the argument
processing (such is the case if the package consists of a number
of sub-packages as in the _PSS.) ACPICA BZ 805.
http://www.acpica.org/bugzilla/show_bug.cgi?id=805
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Some possible warnings with gcc 4+, especially with extended warnings
enabled
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Remove all instances of this obsolete macro, since it is now a
simple reference to ->common.type. There were about 150 invocations
of the macro across 41 files. ACPICA BZ 755.
http://www.acpica.org/bugzilla/show_bug.cgi?id=755
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
also, delete sleep/ and delete ACPI_CFLAGS from Makefile
Signed-off-by: Len Brown <len.brown@intel.com>
|