From: Moore, Robert <robert.moore@in...> - 2005-06-29 16:10:00
Yes, the implicit return code works for EvaluateObject.
In general, code should check for the correct object type before
accessing the object.
There are utility procedures available to execute a method and specify
the expected return type; error otherwise.
> -----Original Message-----
> From: Karol Kozimor [mailto:sziwan@...]
> Sent: Wednesday, June 29, 2005 4:11 AM
> To: Moore, Robert
> Cc: acpi-devel@...; Christian Aichinger
> Subject: Re: [ACPI] oops with asus_acpi on P30/P35
> Thus wrote Christian Aichinger:
> > The oops occurs in asus_acpi.c, line 1016:
> > hotk->model =3D END_MODEL;
> > if (strncmp(model->string.pointer, "L3D", 3) =3D=3D 0) // <-- OOPS
> > hotk->model =3D L3D;
> > Some added debug printk's later it turned out that:
> > model->type =3D=3D ACPI_TYPE_INTEGER
> > model->integer.value =3D=3D 56
> Thanks, I suspected that but I'm really swamped both with Real Work
> my exams so I'm slow even with catching up with the lists...
> > This is why the problem wasn't fixed by your patch, since that
> > resided in the if (model->type =3D=3D ACPI_TYPE_STRING) code-path.
> > I've attatched a patch that works for me, but IMHO it's ugly and
> > only fixes the sympthoms. Why do we get an integer here in the first
> > place?
> Bob, is the implicit return code supposed to trigger also when using
> acpi_evaluate_object()? FYI, this is what we currently do:
> write_acpi_int(hotk->handle, "INIT", 0, &buffer)
> which is fine if the INIT method returns a string (the usual), but
> apparently not if there is no return statement in the method (the P30
> case). The old code assumed the buffer will be null in this case.
> Is that a bug in the ACPICA or should the asus_acpi code cover for
> cases of buffer.type?
> Best regards,
> Karol 'sziwan' Kozimor
From: Karol Kozimor <sziwan@he...> - 2005-06-29 16:36:06
Thus wrote Moore, Robert:
> Yes, the implicit return code works for EvaluateObject.
> In general, code should check for the correct object type before
> accessing the object.
> There are utility procedures available to execute a method and specify
> the expected return type; error otherwise.
I believe the current code allows, in theory, for a situation when a valid
(though useless from the driver's point of view) string is returned in such
Karol 'sziwan' Kozimor