Re: oops with asus_acpi on P30/P35

[Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>]

Thus wrote Christian Aichinger:
> The oops occurs in asus_acpi.c, line 1016:
>     hotk->model = END_MODEL;
> 	if (strncmp(model->string.pointer, "L3D", 3) == 0) // <-- OOPS
> 		hotk->model = L3D;
> 
> Some added debug printk's later it turned out that:
> model->type == ACPI_TYPE_INTEGER
> model->integer.value == 56

Thanks, I suspected that but I'm really swamped both with Real Work and
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 == 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) (drivers/acpi/asus_acpi.c)

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 other
cases of buffer.type?

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click