Commit graph

5 commits

Author SHA1 Message Date
Bob Moore
a18ecf413c [ACPI] ACPICA 20050815
Implemented a full bytewise compare to determine if a table load
request is attempting to load a duplicate table. The compare is
performed if the table signatures and table lengths match. This
will allow different tables with the same OEM Table ID and
revision to be loaded.

Although the BIOS is technically violating the ACPI spec when
this happens -- it does happen -- so Linux must handle it.

Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-29 23:44:25 -04:00
Len Brown
4be44fcd3b [ACPI] Lindent all ACPI files
Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-05 00:45:14 -04:00
Robert Moore
0c9938cc75 [ACPI] ACPICA 20050729 from Bob Moore
Implemented support to ignore an attempt to install/load
a particular ACPI table more than once. Apparently there
exists BIOS code that repeatedly attempts to load the same
SSDT upon certain events. Thanks to Venkatesh Pallipadi.

Restructured the main interface to the AML parser in
order to correctly handle all exceptional conditions. This
will prevent leakage of the OwnerId resource and should
eliminate the AE_OWNER_ID_LIMIT exceptions seen on some
machines. Thanks to Alexey Starikovskiy.

Support for "module level code" has been disabled in this
version due to a number of issues that have appeared
on various machines. The support can be enabled by
defining ACPI_ENABLE_MODULE_LEVEL_CODE during subsystem
compilation. When the issues are fully resolved, the code
will be enabled by default again.

Modified the internal functions for debug print support
to define the FunctionName parameter as a (const char *)
for compatibility with compiler built-in macros such as
__FUNCTION__, etc.

Linted the entire ACPICA source tree for both 32-bit
and 64-bit.

Signed-off-by: Robert Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-30 00:51:39 -04:00
Robert Moore
44f6c01242 ACPICA 20050408 from Bob Moore
Fixed three cases in the interpreter where an "index"
argument to an ASL function was still (internally) 32
bits instead of the required 64 bits.  This was the Index
argument to the Index, Mid, and Match operators.

The "strupr" function is now permanently local
(acpi_ut_strupr), since this is not a POSIX-defined
function and not present in most kernel-level C
libraries. References to the C library strupr function
have been removed from the headers.

Completed the deployment of static
functions/prototypes. All prototypes with the static
attribute have been moved from the headers to the owning
C file.

ACPICA 20050329 from Bob Moore

An error is now generated if an attempt is made to create
a Buffer Field of length zero (A CreateField with a length
operand of zero.)

The interpreter now issues a warning whenever executable
code at the module level is detected during ACPI table
load. This will give some idea of the prevalence of this
type of code.

Implemented support for references to named objects (other
than control methods) within package objects.

Enhanced package object output for the debug
object. Package objects are now completely dumped, showing
all elements.

Enhanced miscellaneous object output for the debug
object. Any object can now be written to the debug object
(for example, a device object can be written, and the type
of the object will be displayed.)

The "static" qualifier has been added to all local
functions across the core subsystem.

The number of "long" lines (> 80 chars) within the source
has been significantly reduced, by about 1/3.

Cleaned up all header files to ensure that all CA/iASL
functions are prototyped (even static functions) and the
formatting is consistent.

Two new header files have been added, acopcode.h and
acnames.h.

Removed several obsolete functions that were no longer
used.

Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-12 00:08:52 -04:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00