Commit graph

10 commits

Author SHA1 Message Date
Bob Moore
77848130e5 ACPICA: Update all copyrights to 2012
Update all copyrights to 2012.

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>
2012-01-17 03:38:51 -05:00
Lin Ming
f654c0fefa ACPICA: Add support for region address conflict checking
Allows drivers to determine if any memory or I/O addresses
will conflict with addresses used by ACPI operation regions.
Introduces a new interface, acpi_check_address_range.

http://marc.info/?t=132251388700002&r=1&w=2

Reported-and-tested-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-17 03:38:50 -05:00
Bob Moore
b4e104eaeb ACPICA: Update all ACPICA copyrights and signons to 2011
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>
2011-01-18 23:48:03 -05:00
Bob Moore
f6a22b0bc4 ACPICA: Standardize integer output for ACPICA warnings/errors
Always use 0x prefix for hex output, use %u for integer output
(all integers are unsigned.)

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>
2010-04-20 10:42:52 -04:00
Bob Moore
a8357b0c95 ACPICA: Update all ACPICA copyrights and signons to 2010
Add 2010 copyright to all module headers and signons, including
the Linux header. This affects virtually every file in the ACPICA
core subsystem, iASL compiler, and all utilities.

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>
2010-01-22 12:30:05 -05:00
Lin Ming
a5fe1a03f7 ACPICA: fix leak of acpi_os_validate_address
http://bugzilla.kernel.org/show_bug.cgi?id=13620

If the dynamic region is created and added to resource list over and over again,
it has the potential to be a memory leak by growing the list every time.

This patch fixes the memory leak, as below

1) add a new field "count" to struct acpi_res_list.

   When inserting, if the region(addr, len) is already in the resource
   list, we just increase "count", otherwise, the region is inserted
   with count=1.

   When deleting, the "count" is decreased, if it's decreased to 0,
   the region is deleted from the resource list.

   With "count", the region with same address and length can only be
   inserted to the resource list once, so prevent potential memory leak.

2) add a new function acpi_os_invalidate_address, which is called when
   region is deleted.

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-27 13:10:35 -04:00
Lin Ming
3362a6badb ACPICA: Region deletion: Ensure region object is removed from handler list
Prevents a possible fault when a dynamic operation region is
deleted. ACPICA BZ 507.

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

Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-27 00:35:51 -04:00
Bob Moore
3371c19c29 ACPICA: Remove ACPI_GET_OBJECT_TYPE macro
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>
2009-03-26 16:38:27 -04:00
Len Brown
e2f7a77728 ACPICA: hide private headers
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-09 03:31:01 -05:00
Len Brown
95b482a8d3 ACPICA: create acpica/ directory
also, delete sleep/ and delete ACPI_CFLAGS from Makefile

Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-09 03:30:47 -05:00
Renamed from drivers/acpi/utilities/utdelete.c (Browse further)