http://bugzilla.kernel.org/show_bug.cgi?id=10686
------- Comment #18 from [EMAIL PROTECTED] 2008-09-10 10:09 -------
Looks like there are a few things going on here.
Apparently, in actuality, there is no support for an "implicit return" for
top-level methods called from the acpi_evaluate_object interface. I don't
remember why this is, but I suspect that it has something to do with preventing
memory leaks caused by adding the implicit return feature and/or that it wasn't
needed at the time we added this feature.
The original test I used was this:
Method (MAIN, 2, NotSerialized)
{
Store (_CRT (), Local0)
Store (Local0, Debug)
}
Which calls the original _CRT code in the bug description above. This test was
able to use the implicit return feature, so we got the incorrect result.
Therefore, I now think that this problem has nothing to do with the implicit
return feature.
In the ACPICA acpi_evaluate_object interface, if there is a buffer provided for
a return value but there is no actual return value, the buffer length is set to
zero:
/*
* If we are expecting a return value, and all went well above,
* copy the return value to an external object.
*/
if (ReturnBuffer)
{
if (!Info->ReturnObject)
{
ReturnBuffer->Length = 0;
}
else
What I think is happening is that the Linux thermal.c driver does not check for
a ReturnBuffer->Length of zero and the failure occurs because it is essentially
looking at random data in the ReturnBuffer->Pointer (data).
ACPICA returns an AE_OK exception in this case because it has no way of knowing
whether a method is "supposed" to return a value or not. Just because a user
buffer was passed in is not sufficient evidence of this condition. It is in
fact the ReturnBuffer->Length field that is used as an output parameter to
indicate the amount of buffer actually used by the return value (in this case,
zero).
I would suggest that the immediate fix to the problem is to update the
acpi_evaluate_integer interface in the Linux file utils.c to examine the length
field. This bug is probably in other drivers and utility functions also.
(acpi_evaluate_reference is one example.)
buffer.length = sizeof(union acpi_object);
buffer.pointer = element;
status = acpi_evaluate_object(handle, pathname, arguments, &buffer);
- if (ACPI_FAILURE(status)) {
+ if (ACPI_FAILURE(status) || !buffer.length) {
acpi_util_eval_error(handle, pathname, status);
kfree(element);
return status;
}
I realize that this problem is somewhat of a direct result of overloading the
buffer.length field to be both an input and output parameter (with resulting
confusion), and may have been an unfortunate decision -- but the immediate bug
fix is above.
In the near future, however, the "predefined method validation" code will be
released which will in fact detect the condition where a method such as _CRT
does not return a value. This doesn't change the fact that in general, the acpi
device drivers should be able to handle a return buffer length of zero.
The new code will produce the message below, and the only debate at this point
is to continue to return AE_OK or go ahead and return AE_AML_NO_RETURN_VALUE.
Since this makes the driver *even more* complex, it could be argued to just
leave the upper ACPICA code as-is, returning AE_OK and a null buffer length.
- ex _CRT
Executing \_CRT
ACPI Warning (nspredef-0251): \_CRT: Missing expected return value [20080910]
BTW, the warning only occurs on the first call to _CRT, ignored later. This
means dmesg will have valuable data but not too much of it.
Bob
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
