[PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Lv Zheng]

There are bug-fixes for AML interpreter upstreamed, fixing some serious
issues found in recent platforms.  These fixes make Linux AML interpreter
more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
be based on such improvements, thus they are good materials for stable.

This patch set can be safely applied to linux-3.8:
commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.

The patch set has passed build/boot tests on the following machines:
  Dell Inspiron Mini 1010 (i386)
  HP Compaq 8200 Elite SFF PC (x86-64)

Bob Moore (4):
  ACPICA: Interpreter: Fix Store() when implicit conversion is not
    possible.
  ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
    BufferField refs.
  ACPICA: Return error if DerefOf resolves to a null package element.
  ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
    field.

 drivers/acpi/acpica/exoparg1.c |   48 +++++++++++--
 drivers/acpi/acpica/exstore.c  |  151 +++++++++++++++++++++++++++-------------
 2 files changed, 146 insertions(+), 53 deletions(-)

Cc: Bob Moore <robert.moore@intel.com>
-- 
1.7.10

[PATCH 1/4] ACPICA: Interpreter: Fix Store() when implicit conversion is not possible.

[Lv Zheng]

From: Bob Moore <robert.moore@intel.com>

commit 3f654bad3257427bea7ba1c4d43a23d99a03622b upstream.

For the cases such as a store of a string to an existing package
object, implement the store as a CopyObject().
This is a small departure from the ACPI specification which states
that the control method should be aborted in this case. However,
ASLTS suite depends on this behavior.

 Cc: <stable@vger.kernel.org> # 3.8.x
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/acpi/acpica/exstore.c |   29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/exstore.c b/drivers/acpi/acpica/exstore.c
index 90431f1..4ff37e8 100644
--- a/drivers/acpi/acpica/exstore.c
+++ b/drivers/acpi/acpica/exstore.c
@@ -487,14 +487,33 @@ acpi_ex_store_object_to_node(union acpi_operand_object *source_desc,
 	default:
 
 		ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
-				  "Storing %s (%p) directly into node (%p) with no implicit conversion\n",
+				  "Storing [%s] (%p) directly into node [%s] (%p)"
+				  " with no implicit conversion\n",
 				  acpi_ut_get_object_type_name(source_desc),
-				  source_desc, node));
+				  source_desc,
+				  acpi_ut_get_object_type_name(target_desc),
+				  node));
 
-		/* No conversions for all other types. Just attach the source object */
+		/*
+		 * No conversions for all other types. Directly store a copy of
+		 * the source object. NOTE: This is a departure from the ACPI
+		 * spec, which states "If conversion is impossible, abort the
+		 * running control method".
+		 *
+		 * This code implements "If conversion is impossible, treat the
+		 * Store operation as a CopyObject".
+		 */
+		status =
+		    acpi_ut_copy_iobject_to_iobject(source_desc, &new_desc,
+						    walk_state);
+		if (ACPI_FAILURE(status)) {
+			return_ACPI_STATUS(status);
+		}
 
-		status = acpi_ns_attach_object(node, source_desc,
-					       source_desc->common.type);
+		status =
+		    acpi_ns_attach_object(node, new_desc,
+					  new_desc->common.type);
+		acpi_ut_remove_reference(new_desc);
 		break;
 	}
 
-- 
1.7.10

[PATCH 2/4] ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs.

[Lv Zheng]

From: Bob Moore <robert.moore@intel.com>

commit 63660e05ec719613b518547b40a1c501c10f0bc4 upstream.

Previously, references to these objects were resolved only to the actual
FieldUnit or BufferField object. The correct behavior is to resolve these
references to an actual value.
The problem is that DerefOf did not resolve these objects to actual
values.  An "Integer" object is simple, return the value.  But a field in
an operation region will require a read operation.  For a BufferField, the
appropriate data must be extracted from the parent buffer.

NOTE: It appears that this issues is present in Windows7 but not
Windows8.

 Cc: <stable@vger.kernel.org> # 3.8.x: 3f654ba: ACPICA: Interpreter: Fix
 Cc: <stable@vger.kernel.org> # 3.8.x
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/acpi/acpica/exoparg1.c |   35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/exoparg1.c b/drivers/acpi/acpica/exoparg1.c
index bbf01e9..1fa1ad6 100644
--- a/drivers/acpi/acpica/exoparg1.c
+++ b/drivers/acpi/acpica/exoparg1.c
@@ -997,11 +997,40 @@ acpi_status acpi_ex_opcode_1A_0T_1R(struct acpi_walk_state *walk_state)
 									 acpi_namespace_node
 									 *)
 									return_desc);
-				}
+					if (!return_desc) {
+						break;
+					}
+
+					/*
+					 * June 2013:
+					 * buffer_fields/field_units require additional resolution
+					 */
+					switch (return_desc->common.type) {
+					case ACPI_TYPE_BUFFER_FIELD:
+					case ACPI_TYPE_LOCAL_REGION_FIELD:
+					case ACPI_TYPE_LOCAL_BANK_FIELD:
+					case ACPI_TYPE_LOCAL_INDEX_FIELD:
+
+						status =
+						    acpi_ex_read_data_from_field
+						    (walk_state, return_desc,
+						     &temp_desc);
+						if (ACPI_FAILURE(status)) {
+							goto cleanup;
+						}
 
-				/* Add another reference to the object! */
+						return_desc = temp_desc;
+						break;
 
-				acpi_ut_add_reference(return_desc);
+					default:
+
+						/* Add another reference to the object */
+
+						acpi_ut_add_reference
+						    (return_desc);
+						break;
+					}
+				}
 				break;
 
 			default:
-- 
1.7.10

[PATCH 3/4] ACPICA: Return error if DerefOf resolves to a null package element.

[Lv Zheng]

From: Bob Moore <robert.moore@intel.com>

commit a50abf4842dd7d603a2ad6dcc7f1467fd2a66f03 upstream.

Disallow the dereference of a reference (via index) to an uninitialized
package element. Provides compatibility with other ACPI
implementations. ACPICA BZ 1003.

 Cc: <stable@vger.kernel.org> # 3.8.x: 3f654ba: ACPICA: Interpreter: Fix
 Cc: <stable@vger.kernel.org> # 3.8.x: 63660e0: ACPICA: DeRefOf operator:
 Cc: <stable@vger.kernel.org> # 3.8.x
References: https://bugs.acpica.org/show_bug.cgi?id=431
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/acpi/acpica/exoparg1.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/exoparg1.c b/drivers/acpi/acpica/exoparg1.c
index 1fa1ad6..c9f1a21 100644
--- a/drivers/acpi/acpica/exoparg1.c
+++ b/drivers/acpi/acpica/exoparg1.c
@@ -969,10 +969,17 @@ acpi_status acpi_ex_opcode_1A_0T_1R(struct acpi_walk_state *walk_state)
 					 */
 					return_desc =
 					    *(operand[0]->reference.where);
-					if (return_desc) {
-						acpi_ut_add_reference
-						    (return_desc);
+					if (!return_desc) {
+						/*
+						 * Element is NULL, do not allow the dereference.
+						 * This provides compatibility with other ACPI
+						 * implementations.
+						 */
+						return_ACPI_STATUS
+						    (AE_AML_UNINITIALIZED_ELEMENT);
 					}
+
+					acpi_ut_add_reference(return_desc);
 					break;
 
 				default:
-- 
1.7.10

[PATCH 4/4] ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a field.

[Lv Zheng]

From: Bob Moore <robert.moore@intel.com>

commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 upstream.

This change fixes a problem where a Store operation to an ArgX object
that contained a reference to a field object did not complete the
automatic dereference and then write to the actual field object.
Instead, the object type of the field object was inadvertently changed
to match the type of the source operand. The new behavior will actually
write to the field object (buffer field or field unit), thus matching
the correct ACPI-defined behavior.

 Cc: <stable@vger.kernel.org> # 3.8.x: 3f654ba: ACPICA: Interpreter: Fix
 Cc: <stable@vger.kernel.org> # 3.8.x: 63660e0: ACPICA: DeRefOf operator:
 Cc: <stable@vger.kernel.org> # 3.8.x: a50abf4: ACPICA: Return error if
 Cc: <stable@vger.kernel.org> # 3.8.x
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
---
 drivers/acpi/acpica/exstore.c |  166 +++++++++++++++++++++++++----------------
 1 file changed, 102 insertions(+), 64 deletions(-)

diff --git a/drivers/acpi/acpica/exstore.c b/drivers/acpi/acpica/exstore.c
index 4ff37e8..cd7079d 100644
--- a/drivers/acpi/acpica/exstore.c
+++ b/drivers/acpi/acpica/exstore.c
@@ -57,6 +57,11 @@ acpi_ex_store_object_to_index(union acpi_operand_object *val_desc,
 			      union acpi_operand_object *dest_desc,
 			      struct acpi_walk_state *walk_state);
 
+static acpi_status
+acpi_ex_store_direct_to_node(union acpi_operand_object *source_desc,
+			     struct acpi_namespace_node *node,
+			     struct acpi_walk_state *walk_state);
+
 /*******************************************************************************
  *
  * FUNCTION:    acpi_ex_store
@@ -376,7 +381,11 @@ acpi_ex_store_object_to_index(union acpi_operand_object *source_desc,
  *              When storing into an object the data is converted to the
  *              target object type then stored in the object. This means
  *              that the target object type (for an initialized target) will
- *              not be changed by a store operation.
+ *              not be changed by a store operation. A copy_object can change
+ *              the target type, however.
+ *
+ *              The implicit_conversion flag is set to NO/FALSE only when
+ *              storing to an arg_x -- as per the rules of the ACPI spec.
  *
  *              Assumes parameters are already validated.
  *
@@ -400,7 +409,7 @@ acpi_ex_store_object_to_node(union acpi_operand_object *source_desc,
 	target_type = acpi_ns_get_type(node);
 	target_desc = acpi_ns_get_attached_object(node);
 
-	ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Storing %p(%s) into node %p(%s)\n",
+	ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Storing %p (%s) to node %p (%s)\n",
 			  source_desc,
 			  acpi_ut_get_object_type_name(source_desc), node,
 			  acpi_ut_get_type_name(target_type)));
@@ -414,46 +423,31 @@ acpi_ex_store_object_to_node(union acpi_operand_object *source_desc,
 		return_ACPI_STATUS(status);
 	}
 
-	/* If no implicit conversion, drop into the default case below */
-
-	if ((!implicit_conversion) ||
-	    ((walk_state->opcode == AML_COPY_OP) &&
-	     (target_type != ACPI_TYPE_LOCAL_REGION_FIELD) &&
-	     (target_type != ACPI_TYPE_LOCAL_BANK_FIELD) &&
-	     (target_type != ACPI_TYPE_LOCAL_INDEX_FIELD))) {
-		/*
-		 * Force execution of default (no implicit conversion). Note:
-		 * copy_object does not perform an implicit conversion, as per the ACPI
-		 * spec -- except in case of region/bank/index fields -- because these
-		 * objects must retain their original type permanently.
-		 */
-		target_type = ACPI_TYPE_ANY;
-	}
-
 	/* Do the actual store operation */
 
 	switch (target_type) {
-	case ACPI_TYPE_BUFFER_FIELD:
-	case ACPI_TYPE_LOCAL_REGION_FIELD:
-	case ACPI_TYPE_LOCAL_BANK_FIELD:
-	case ACPI_TYPE_LOCAL_INDEX_FIELD:
-
-		/* For fields, copy the source data to the target field. */
-
-		status = acpi_ex_write_data_to_field(source_desc, target_desc,
-						     &walk_state->result_obj);
-		break;
-
 	case ACPI_TYPE_INTEGER:
 	case ACPI_TYPE_STRING:
 	case ACPI_TYPE_BUFFER:
 
 		/*
-		 * These target types are all of type Integer/String/Buffer, and
-		 * therefore support implicit conversion before the store.
-		 *
-		 * Copy and/or convert the source object to a new target object
+		 * The simple data types all support implicit source operand
+		 * conversion before the store.
 		 */
+
+		if ((walk_state->opcode == AML_COPY_OP) || !implicit_conversion) {
+			/*
+			 * However, copy_object and Stores to arg_x do not perform
+			 * an implicit conversion, as per the ACPI specification.
+			 * A direct store is performed instead.
+			 */
+			status = acpi_ex_store_direct_to_node(source_desc, node,
+							      walk_state);
+			break;
+		}
+
+		/* Store with implicit source operand conversion support */
+
 		status =
 		    acpi_ex_store_object_to_object(source_desc, target_desc,
 						   &new_desc, walk_state);
@@ -467,13 +461,12 @@ acpi_ex_store_object_to_node(union acpi_operand_object *source_desc,
 			 * the Name's type to that of the value being stored in it.
 			 * source_desc reference count is incremented by attach_object.
 			 *
-			 * Note: This may change the type of the node if an explicit store
-			 * has been performed such that the node/object type has been
-			 * changed.
+			 * Note: This may change the type of the node if an explicit
+			 * store has been performed such that the node/object type
+			 * has been changed.
 			 */
-			status =
-			    acpi_ns_attach_object(node, new_desc,
-						  new_desc->common.type);
+			status = acpi_ns_attach_object(node, new_desc,
+						       new_desc->common.type);
 
 			ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
 					  "Store %s into %s via Convert/Attach\n",
@@ -484,38 +477,83 @@ acpi_ex_store_object_to_node(union acpi_operand_object *source_desc,
 		}
 		break;
 
-	default:
-
-		ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
-				  "Storing [%s] (%p) directly into node [%s] (%p)"
-				  " with no implicit conversion\n",
-				  acpi_ut_get_object_type_name(source_desc),
-				  source_desc,
-				  acpi_ut_get_object_type_name(target_desc),
-				  node));
+	case ACPI_TYPE_BUFFER_FIELD:
+	case ACPI_TYPE_LOCAL_REGION_FIELD:
+	case ACPI_TYPE_LOCAL_BANK_FIELD:
+	case ACPI_TYPE_LOCAL_INDEX_FIELD:
+		/*
+		 * For all fields, always write the source data to the target
+		 * field. Any required implicit source operand conversion is
+		 * performed in the function below as necessary. Note, field
+		 * objects must retain their original type permanently.
+		 */
+		status = acpi_ex_write_data_to_field(source_desc, target_desc,
+						     &walk_state->result_obj);
+		break;
 
+	default:
 		/*
 		 * No conversions for all other types. Directly store a copy of
-		 * the source object. NOTE: This is a departure from the ACPI
-		 * spec, which states "If conversion is impossible, abort the
-		 * running control method".
+		 * the source object. This is the ACPI spec-defined behavior for
+		 * the copy_object operator.
 		 *
-		 * This code implements "If conversion is impossible, treat the
-		 * Store operation as a CopyObject".
+		 * NOTE: For the Store operator, this is a departure from the
+		 * ACPI spec, which states "If conversion is impossible, abort
+		 * the running control method". Instead, this code implements
+		 * "If conversion is impossible, treat the Store operation as
+		 * a CopyObject".
 		 */
-		status =
-		    acpi_ut_copy_iobject_to_iobject(source_desc, &new_desc,
-						    walk_state);
-		if (ACPI_FAILURE(status)) {
-			return_ACPI_STATUS(status);
-		}
-
-		status =
-		    acpi_ns_attach_object(node, new_desc,
-					  new_desc->common.type);
-		acpi_ut_remove_reference(new_desc);
+		status = acpi_ex_store_direct_to_node(source_desc, node,
+						      walk_state);
 		break;
 	}
 
 	return_ACPI_STATUS(status);
 }
+
+/*******************************************************************************
+ *
+ * FUNCTION:    acpi_ex_store_direct_to_node
+ *
+ * PARAMETERS:  source_desc             - Value to be stored
+ *              node                    - Named object to receive the value
+ *              walk_state              - Current walk state
+ *
+ * RETURN:      Status
+ *
+ * DESCRIPTION: "Store" an object directly to a node. This involves a copy
+ *              and an attach.
+ *
+ ******************************************************************************/
+
+static acpi_status
+acpi_ex_store_direct_to_node(union acpi_operand_object *source_desc,
+			     struct acpi_namespace_node *node,
+			     struct acpi_walk_state *walk_state)
+{
+	acpi_status status;
+	union acpi_operand_object *new_desc;
+
+	ACPI_FUNCTION_TRACE(ex_store_direct_to_node);
+
+	ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
+			  "Storing [%s] (%p) directly into node [%s] (%p)"
+			  " with no implicit conversion\n",
+			  acpi_ut_get_object_type_name(source_desc),
+			  source_desc, acpi_ut_get_type_name(node->type),
+			  node));
+
+	/* Copy the source object to a new object */
+
+	status =
+	    acpi_ut_copy_iobject_to_iobject(source_desc, &new_desc, walk_state);
+	if (ACPI_FAILURE(status)) {
+		return_ACPI_STATUS(status);
+	}
+
+	/* Attach the new object to the node */
+
+	status = acpi_ns_attach_object(node, new_desc, new_desc->common.type);
+	acpi_ut_remove_reference(new_desc);
+	return_ACPI_STATUS(status);
+}
-- 
1.7.10

Re: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Rafael J. Wysocki]

On Thursday, October 31, 2013 09:07:40 AM Lv Zheng wrote:
> There are bug-fixes for AML interpreter upstreamed, fixing some serious
> issues found in recent platforms.  These fixes make Linux AML interpreter
> more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
> be based on such improvements, thus they are good materials for stable.
> 
> This patch set can be safely applied to linux-3.8:
> commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> 
> The patch set has passed build/boot tests on the following machines:
>   Dell Inspiron Mini 1010 (i386)
>   HP Compaq 8200 Elite SFF PC (x86-64)
> 
> Bob Moore (4):
>   ACPICA: Interpreter: Fix Store() when implicit conversion is not
>     possible.
>   ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
>     BufferField refs.
>   ACPICA: Return error if DerefOf resolves to a null package element.
>   ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
>     field.

Hi Greg,

Please take patches [1-4/4] for stable.

Rafael

Re: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Greg Kroah-Hartman]

On Thu, Oct 31, 2013 at 12:39:21PM +0100, Rafael J. Wysocki wrote:
> On Thursday, October 31, 2013 09:07:40 AM Lv Zheng wrote:
> > There are bug-fixes for AML interpreter upstreamed, fixing some serious
> > issues found in recent platforms.  These fixes make Linux AML interpreter
> > more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
> > be based on such improvements, thus they are good materials for stable.
> > 
> > This patch set can be safely applied to linux-3.8:
> > commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> > 
> > The patch set has passed build/boot tests on the following machines:
> >   Dell Inspiron Mini 1010 (i386)
> >   HP Compaq 8200 Elite SFF PC (x86-64)
> > 
> > Bob Moore (4):
> >   ACPICA: Interpreter: Fix Store() when implicit conversion is not
> >     possible.
> >   ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
> >     BufferField refs.
> >   ACPICA: Return error if DerefOf resolves to a null package element.
> >   ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
> >     field.
> 
> Hi Greg,
> 
> Please take patches [1-4/4] for stable.

"Which" stable tree?

I don't do 3.8, it's long been end-of-life, although one company is
trying to keep it alive, but that's not me.

I'm only handling 3.4, 3.10, and 3.11 stable trees right now, which
one(s) should these be applied to?

thanks,

greg k-h

Re: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Rafael J. Wysocki]

On Thursday, October 31, 2013 05:08:50 AM Greg Kroah-Hartman wrote:
> On Thu, Oct 31, 2013 at 12:39:21PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, October 31, 2013 09:07:40 AM Lv Zheng wrote:
> > > There are bug-fixes for AML interpreter upstreamed, fixing some serious
> > > issues found in recent platforms.  These fixes make Linux AML interpreter
> > > more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
> > > be based on such improvements, thus they are good materials for stable.
> > > 
> > > This patch set can be safely applied to linux-3.8:
> > > commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> > > 
> > > The patch set has passed build/boot tests on the following machines:
> > >   Dell Inspiron Mini 1010 (i386)
> > >   HP Compaq 8200 Elite SFF PC (x86-64)
> > > 
> > > Bob Moore (4):
> > >   ACPICA: Interpreter: Fix Store() when implicit conversion is not
> > >     possible.
> > >   ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
> > >     BufferField refs.
> > >   ACPICA: Return error if DerefOf resolves to a null package element.
> > >   ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
> > >     field.
> > 
> > Hi Greg,
> > 
> > Please take patches [1-4/4] for stable.
> 
> "Which" stable tree?
> 
> I don't do 3.8, it's long been end-of-life, although one company is
> trying to keep it alive, but that's not me.
> 
> I'm only handling 3.4, 3.10, and 3.11 stable trees right now, which
> one(s) should these be applied to?

3.10.x and 3.11.x then.

Lv, do the original mainline commits apply to these kernels?

Rafael

Re: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Kamal Mostafa]

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

On Thu, 2013-10-31 at 09:07 +0800, Lv Zheng wrote:
> There are bug-fixes for AML interpreter upstreamed, fixing some serious
> issues found in recent platforms.  These fixes make Linux AML interpreter
> more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
> be based on such improvements, thus they are good materials for stable.
> 
> This patch set can be safely applied to linux-3.8:
> commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> 
> The patch set has passed build/boot tests on the following machines:
>   Dell Inspiron Mini 1010 (i386)
>   HP Compaq 8200 Elite SFF PC (x86-64)
> 
> Bob Moore (4):
>   ACPICA: Interpreter: Fix Store() when implicit conversion is not
>     possible.
>   ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
>     BufferField refs.
>   ACPICA: Return error if DerefOf resolves to a null package element.
>   ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
>     field.
> 
>  drivers/acpi/acpica/exoparg1.c |   48 +++++++++++--
>  drivers/acpi/acpica/exstore.c  |  151 +++++++++++++++++++++++++++-------------
>  2 files changed, 146 insertions(+), 53 deletions(-)
> 
> Cc: Bob Moore <robert.moore@intel.com>


OK, I'm queuing these up for 3.8-stable (they'll appear in v3.8.13.13).
Thanks very much Lv, Rafael, and Bob.

 -Kamal


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Zheng, Lv]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3764 bytes --]

> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Thursday, October 31, 2013 8:22 PM
> 
> On Thursday, October 31, 2013 05:08:50 AM Greg Kroah-Hartman wrote:
> > On Thu, Oct 31, 2013 at 12:39:21PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, October 31, 2013 09:07:40 AM Lv Zheng wrote:
> > > > There are bug-fixes for AML interpreter upstreamed, fixing some serious
> > > > issues found in recent platforms.  These fixes make Linux AML interpreter
> > > > more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
> > > > be based on such improvements, thus they are good materials for stable.
> > > >
> > > > This patch set can be safely applied to linux-3.8:
> > > > commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> > > >
> > > > The patch set has passed build/boot tests on the following machines:
> > > >   Dell Inspiron Mini 1010 (i386)
> > > >   HP Compaq 8200 Elite SFF PC (x86-64)
> > > >
> > > > Bob Moore (4):
> > > >   ACPICA: Interpreter: Fix Store() when implicit conversion is not
> > > >     possible.
> > > >   ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
> > > >     BufferField refs.
> > > >   ACPICA: Return error if DerefOf resolves to a null package element.
> > > >   ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
> > > >     field.
> > >
> > > Hi Greg,
> > >
> > > Please take patches [1-4/4] for stable.
> >
> > "Which" stable tree?
> >
> > I don't do 3.8, it's long been end-of-life, although one company is
> > trying to keep it alive, but that's not me.
> >
> > I'm only handling 3.4, 3.10, and 3.11 stable trees right now, which
> > one(s) should these be applied to?
> 
> 3.10.x and 3.11.x then.
> 
> Lv, do the original mainline commits apply to these kernels?
> 
> Rafael

Hi, Rafael and Greg

I checked the back port dependencies since v3.8:
1. [PATCH 1] belongs to v3.9.
2. [PATCH 4] includes an empty line belonging to a coding style fix affecting this series (between [PATCH 3] and [PATCH 4]).
Thus,
1. For v3.10:
    [PATCH 1]: It's already in the repo, so please drop it.
    [PATCH 2-4]: They can be used directly as 3.10.x stable materials.
2. For v3.11:
    [PATCH 1]: It's already in the repo, so please drop it.
    [PATCH 2-3]: They can be used directly as 3.11.x stable materials.
    [PATCH 4]: The original commit from Linus' tree should be used instead.

 I checked the commit log since v3.4.
 There is no functional change done to the AML executer between v3.4 and v3.8.
 The problem is there is a coding style fix affecting this series (between v3.4 and [PATCH 1]).
 I generated the following diff block before applying [PATCH 1], and obtained a successful build/boot to a v3.4 kernel with these patches applied.
Thus,
1. For v3.4:
    [PATCH 1]: You can merge this diff block to [PATCH 1] or simply modify the [PATCH 1] by manually adding this white space.
    [PATCH 2-4]: They can be used directly as 3.4.x stable materials.

---
Index: linux-acpica/drivers/acpi/acpica/exstore.c
===================================================================
--- linux-acpica.orig/drivers/acpi/acpica/exstore.c
+++ linux-acpica/drivers/acpi/acpica/exstore.c
@@ -491,7 +491,7 @@ acpi_ex_store_object_to_node(union acpi_
 				  acpi_ut_get_object_type_name(source_desc),
 				  source_desc, node));
 
-		/* No conversions for all other types.  Just attach the source object */
+		/* No conversions for all other types. Just attach the source object */
 
 		status = acpi_ns_attach_object(node, source_desc,
 					       source_desc->common.type);
---

Thanks and best regards
-Lv
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Greg Kroah-Hartman]

On Fri, Nov 01, 2013 at 02:58:16AM +0000, Zheng, Lv wrote:
> > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > Sent: Thursday, October 31, 2013 8:22 PM
> > 
> > On Thursday, October 31, 2013 05:08:50 AM Greg Kroah-Hartman wrote:
> > > On Thu, Oct 31, 2013 at 12:39:21PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, October 31, 2013 09:07:40 AM Lv Zheng wrote:
> > > > > There are bug-fixes for AML interpreter upstreamed, fixing some serious
> > > > > issues found in recent platforms.  These fixes make Linux AML interpreter
> > > > > more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
> > > > > be based on such improvements, thus they are good materials for stable.
> > > > >
> > > > > This patch set can be safely applied to linux-3.8:
> > > > > commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> > > > >
> > > > > The patch set has passed build/boot tests on the following machines:
> > > > >   Dell Inspiron Mini 1010 (i386)
> > > > >   HP Compaq 8200 Elite SFF PC (x86-64)
> > > > >
> > > > > Bob Moore (4):
> > > > >   ACPICA: Interpreter: Fix Store() when implicit conversion is not
> > > > >     possible.
> > > > >   ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
> > > > >     BufferField refs.
> > > > >   ACPICA: Return error if DerefOf resolves to a null package element.
> > > > >   ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
> > > > >     field.
> > > >
> > > > Hi Greg,
> > > >
> > > > Please take patches [1-4/4] for stable.
> > >
> > > "Which" stable tree?
> > >
> > > I don't do 3.8, it's long been end-of-life, although one company is
> > > trying to keep it alive, but that's not me.
> > >
> > > I'm only handling 3.4, 3.10, and 3.11 stable trees right now, which
> > > one(s) should these be applied to?
> > 
> > 3.10.x and 3.11.x then.
> > 
> > Lv, do the original mainline commits apply to these kernels?
> > 
> > Rafael
> 
> Hi, Rafael and Greg
> 
> I checked the back port dependencies since v3.8:
> 1. [PATCH 1] belongs to v3.9.
> 2. [PATCH 4] includes an empty line belonging to a coding style fix affecting this series (between [PATCH 3] and [PATCH 4]).
> Thus,
> 1. For v3.10:
>     [PATCH 1]: It's already in the repo, so please drop it.
>     [PATCH 2-4]: They can be used directly as 3.10.x stable materials.
> 2. For v3.11:
>     [PATCH 1]: It's already in the repo, so please drop it.
>     [PATCH 2-3]: They can be used directly as 3.11.x stable materials.
>     [PATCH 4]: The original commit from Linus' tree should be used instead.
> 
>  I checked the commit log since v3.4.
>  There is no functional change done to the AML executer between v3.4 and v3.8.
>  The problem is there is a coding style fix affecting this series (between v3.4 and [PATCH 1]).
>  I generated the following diff block before applying [PATCH 1], and obtained a successful build/boot to a v3.4 kernel with these patches applied.
> Thus,
> 1. For v3.4:
>     [PATCH 1]: You can merge this diff block to [PATCH 1] or simply modify the [PATCH 1] by manually adding this white space.
>     [PATCH 2-4]: They can be used directly as 3.4.x stable materials.

Ok, I think I have this all properly queued up for 3.4, 3.10, and
3.11-stable trees, can you please check and verify I didn't mess
anything up?

thanks,

greg k-h

RE: [PATCH 0/4] ACPICA: Stable material of ACPI executer fixes for linux-3.8.

[Zheng, Lv]

> From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
> Sent: Sunday, November 24, 2013 11:22 AM
> 
> On Fri, Nov 01, 2013 at 02:58:16AM +0000, Zheng, Lv wrote:
> > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > Sent: Thursday, October 31, 2013 8:22 PM
> > >
> > > On Thursday, October 31, 2013 05:08:50 AM Greg Kroah-Hartman wrote:
> > > > On Thu, Oct 31, 2013 at 12:39:21PM +0100, Rafael J. Wysocki wrote:
> > > > > On Thursday, October 31, 2013 09:07:40 AM Lv Zheng wrote:
> > > > > > There are bug-fixes for AML interpreter upstreamed, fixing some serious
> > > > > > issues found in recent platforms.  These fixes make Linux AML interpreter
> > > > > > more ACPI 2.0 ASL concept compliant.  Further AML interpreter fixes should
> > > > > > be based on such improvements, thus they are good materials for stable.
> > > > > >
> > > > > > This patch set can be safely applied to linux-3.8:
> > > > > > commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 upstream.
> > > > > >
> > > > > > The patch set has passed build/boot tests on the following machines:
> > > > > >   Dell Inspiron Mini 1010 (i386)
> > > > > >   HP Compaq 8200 Elite SFF PC (x86-64)
> > > > > >
> > > > > > Bob Moore (4):
> > > > > >   ACPICA: Interpreter: Fix Store() when implicit conversion is not
> > > > > >     possible.
> > > > > >   ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
> > > > > >     BufferField refs.
> > > > > >   ACPICA: Return error if DerefOf resolves to a null package element.
> > > > > >   ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
> > > > > >     field.
> > > > >
> > > > > Hi Greg,
> > > > >
> > > > > Please take patches [1-4/4] for stable.
> > > >
> > > > "Which" stable tree?
> > > >
> > > > I don't do 3.8, it's long been end-of-life, although one company is
> > > > trying to keep it alive, but that's not me.
> > > >
> > > > I'm only handling 3.4, 3.10, and 3.11 stable trees right now, which
> > > > one(s) should these be applied to?
> > >
> > > 3.10.x and 3.11.x then.
> > >
> > > Lv, do the original mainline commits apply to these kernels?
> > >
> > > Rafael
> >
> > Hi, Rafael and Greg
> >
> > I checked the back port dependencies since v3.8:
> > 1. [PATCH 1] belongs to v3.9.
> > 2. [PATCH 4] includes an empty line belonging to a coding style fix affecting this series (between [PATCH 3] and [PATCH 4]).
> > Thus,
> > 1. For v3.10:
> >     [PATCH 1]: It's already in the repo, so please drop it.
> >     [PATCH 2-4]: They can be used directly as 3.10.x stable materials.
> > 2. For v3.11:
> >     [PATCH 1]: It's already in the repo, so please drop it.
> >     [PATCH 2-3]: They can be used directly as 3.11.x stable materials.
> >     [PATCH 4]: The original commit from Linus' tree should be used instead.
> >
> >  I checked the commit log since v3.4.
> >  There is no functional change done to the AML executer between v3.4 and v3.8.
> >  The problem is there is a coding style fix affecting this series (between v3.4 and [PATCH 1]).
> >  I generated the following diff block before applying [PATCH 1], and obtained a successful build/boot to a v3.4 kernel with these
> patches applied.
> > Thus,
> > 1. For v3.4:
> >     [PATCH 1]: You can merge this diff block to [PATCH 1] or simply modify the [PATCH 1] by manually adding this white space.
> >     [PATCH 2-4]: They can be used directly as 3.4.x stable materials.
> 
> Ok, I think I have this all properly queued up for 3.4, 3.10, and
> 3.11-stable trees, can you please check and verify I didn't mess
> anything up?

I pulled and checked, they are all correct.

Thanks and best regards
-Lv

> 
> thanks,
> 
> greg k-h