[ACPI] ACPICA 20051117

Fixed a problem in the AML parser where the method thread
count could be decremented below zero if any errors
occurred during the method parse phase. This should
eliminate AE_AML_METHOD_LIMIT exceptions seen on some
machines. This also fixed a related regression with the
mechanism that detects and corrects methods that cannot
properly handle reentrancy (related to the deployment of
the new OwnerId mechanism.)

Eliminated the pre-parsing of control methods (to detect
errors) during table load. Related to the problem above,
this was causing unwind issues if any errors occurred
during the parse, and it seemed to be overkill. A table
load should not be aborted if there are problems with
any single control method, thus rendering this feature
rather pointless.

Fixed a problem with the new table-driven resource manager
where an internal buffer overflow could occur for small
resource templates.

Implemented a new external interface, acpi_get_vendor_resource()
This interface will find and return a vendor-defined
resource descriptor within a _CRS or _PRS
method via an ACPI 3.0 UUID match. (from Bjorn Helgaas)

Removed the length limit (200) on string objects as
per the upcoming ACPI 3.0A specification. This affects
the following areas of the interpreter: 1) any implicit
conversion of a Buffer to a String, 2) a String object
result of the ASL Concatentate operator, 3) the String
object result of the ASL ToString operator.

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

1 files changed, 26 insertions, 8 deletions

diff --git a/drivers/acpi/utilities/utmisc.c b/drivers/acpi/utilities/utmisc.c
index 2a9110c0639..89efba7bf44 100644
--- a/drivers/acpi/utilities/utmisc.c
+++ b/drivers/acpi/utilities/utmisc.c
@@ -63,6 +63,7 @@ ACPI_MODULE_NAME("utmisc")
 acpi_status acpi_ut_allocate_owner_id(acpi_owner_id * owner_id)
 {
 	acpi_native_uint i;
+	acpi_native_uint j;
 	acpi_status status;
 
 	ACPI_FUNCTION_TRACE("ut_allocate_owner_id");
@@ -82,29 +83,46 @@ acpi_status acpi_ut_allocate_owner_id(acpi_owner_id * owner_id)
 		return_ACPI_STATUS(status);
 	}
 
-	/* Find a free owner ID */
+	/*
+	 * Find a free owner ID, cycle through all possible IDs on repeated
+	 * allocations. Note: Index for next possible ID is equal to the value
+	 * of the last allocated ID.
+	 */
+	for (i = 0, j = acpi_gbl_last_owner_id; i < 32; i++, j++) {
+		if (j >= 32) {
+			j = 0;	/* Wraparound to ID start */
+		}
+
+		if (!(acpi_gbl_owner_id_mask & (1 << j))) {
+			/*
+			 * Found a free ID. The actual ID is the bit index plus one,
+			 * making zero an invalid Owner ID. Save this as the last ID
+			 * allocated and update the global ID mask.
+			 */
+			acpi_gbl_last_owner_id = (acpi_owner_id) (j + 1);
+			*owner_id = acpi_gbl_last_owner_id;
 
-	for (i = 0; i < 32; i++) {
-		if (!(acpi_gbl_owner_id_mask & (1 << i))) {
 			ACPI_DEBUG_PRINT((ACPI_DB_VALUES,
 					  "Current owner_id mask: %8.8X New ID: %2.2X\n",
 					  acpi_gbl_owner_id_mask,
-					  (unsigned int)(i + 1)));
+					  (unsigned int)
+					  acpi_gbl_last_owner_id));
 
-			acpi_gbl_owner_id_mask |= (1 << i);
-			*owner_id = (acpi_owner_id) (i + 1);
+			acpi_gbl_owner_id_mask |= (1 << j);
 			goto exit;
 		}
 	}
 
 	/*
-	 * If we are here, all owner_ids have been allocated. This probably should
+	 * All owner_ids have been allocated. This typically should
 	 * not happen since the IDs are reused after deallocation. The IDs are
 	 * allocated upon table load (one per table) and method execution, and
 	 * they are released when a table is unloaded or a method completes
 	 * execution.
+	 *
+	 * If this error happens, there may be very deep nesting of invoked control
+	 * methods, or there may be a bug where the IDs are not released.
 	 */
-	*owner_id = 0;
 	status = AE_OWNER_ID_LIMIT;
 	ACPI_REPORT_ERROR(("Could not allocate new owner_id (32 max), AE_OWNER_ID_LIMIT\n"));