All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Aichinger <Greek0-hi6Y0CQ0nG0@public.gmane.org>
To: Timo Hoenig <thoenig-dCxI//HcOdFeoWH0uzbU5w@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	"Hanno Böck" <mail-60OJuG18Xr6zQB+pC5nmwQ@public.gmane.org>,
	"Karol Kozimor" <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>,
	"Carl-Daniel Hailfinger"
	<c-d.hailfinger.devel.2005-hi6Y0CQ0nG0@public.gmane.org>,
	"Moore,
	Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: oops with asus_acpi on P30/P35
Date: Wed, 21 Sep 2005 17:08:51 +0200	[thread overview]
Message-ID: <20050921150851.GU22403@orest.greek0.net> (raw)
In-Reply-To: <1127309993.26683.15.camel-1iW2g3EOClSoYr4blSSd5g@public.gmane.org>

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

On Wed, Sep 21, 2005 at 03:39:53PM +0200, Timo Hoenig wrote:
> On Wed, 2005-09-21 at 11:08 +0200, Christian Aichinger wrote:
> > If this fix still breaks other laptops I'd really be puzzled, since
> > currently the value is dereferenced later when doing the string
> > comparisons. So the patch at least shouldn't break it more than it
> > already is ;)
> 
> I can confirm that your patch works fine for the W5A which previously
> needed the mentioned workaround.  But this single case of success should
> not be taken as proof.  More testing would be reasonable.

The old patch was kind of a "Want to get this thing to work
for me" version. This one is more the "Let's get this thing finally
fixed in mainline" version now.

The patch only changes the behavior if the INIT method returns an
integer instead of a string, or a pointer to an integer or similar.

Now if an integer is returned this breaks the assumption in the
whole rest of the function, namely that model->xxx.pointer can be
dereferenced. This works for ACPI_TYPE_STRING and ACPI_TYPE_BUFFER.
Why the old patch broke you is probably because the INIT method
in your DSDT returns a _BUFFER instead of an _STRING.

In any other case (including ACPI_TYPE_INTEGER) dereferencing
model->pointer (or whatever's stored at that offset) WILL lead to an
oops.

Pointer magic isn't possible in AML AFAIK and it would be sheer luck
(and still a bug) if dereferencing some random integer gotten from
some AML function would actually work.

That's what I ment with the "if this breaks something it was at
least as broken before". If this patch changes the behavior for you,
you got a kernel oops without it.

It would probably be nice to add a check for
(model->type == string || buffer) for defensive-programming's sake.
However that can (and should probably) be done later on.

Cheers,
Christian Aichinger

PS: Would be nice if you could test my assumption that model->type
is really ACPI_TYPE_BUFFER on your laptop, by pasting a dmesg
snippet with that patch applied (should apply to vanilla -rc2):

diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
--- a/drivers/acpi/asus_acpi.c
+++ b/drivers/acpi/asus_acpi.c
@@ -1006,6 +1006,7 @@ static int __init asus_hotk_get_info(voi
        }
 
        model = (union acpi_object *)buffer.pointer;
+       printk(KERN_NOTICE "  DEBUG: model->type == %d\n", model->type);
        if (model->type == ACPI_TYPE_STRING) {
                printk(KERN_NOTICE "  %s model detected, ",
                       model->string.pointer);

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2005-09-21 15:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-18  0:45 oops with asus_acpi on P30/P35 Christian Aichinger
     [not found] ` <20050618004506.GE3690-eJYrgmUciHpxYM3rXe3Iuw@public.gmane.org>
2005-06-29 11:10   ` Karol Kozimor
     [not found]     ` <20050629111044.GA2910-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
2005-06-29 15:10       ` Carl-Daniel Hailfinger
     [not found]         ` <42C2BA01.2060806-hi6Y0CQ0nG0@public.gmane.org>
2005-06-29 15:50           ` Karol Kozimor
     [not found]             ` <20050629155015.GB14659-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
2005-08-19 15:49               ` Hanno Böck
     [not found]                 ` <200508191749.18016.mail-60OJuG18Xr6zQB+pC5nmwQ@public.gmane.org>
2005-08-21 14:36                   ` Timo Hoenig
     [not found]                     ` <1124634977.4952.9.camel-dCxI//HcOdFeoWH0uzbU5w@public.gmane.org>
2005-09-21  9:08                       ` Christian Aichinger
     [not found]                         ` <20050921090810.GS22403-eJYrgmUciHpxYM3rXe3Iuw@public.gmane.org>
2005-09-21 11:47                           ` Hanno Böck
     [not found]                             ` <200509211347.13322.mail-60OJuG18Xr6zQB+pC5nmwQ@public.gmane.org>
2005-09-21 14:39                               ` Christian Aichinger
2005-09-21 13:39                           ` Timo Hoenig
     [not found]                             ` <1127309993.26683.15.camel-1iW2g3EOClSoYr4blSSd5g@public.gmane.org>
2005-09-21 15:08                               ` Christian Aichinger [this message]
     [not found]                                 ` <20050921150851.GU22403-eJYrgmUciHpxYM3rXe3Iuw@public.gmane.org>
2005-09-22 12:13                                   ` Karol Kozimor
     [not found]                                     ` <20050922121342.GA9462-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
2005-09-22 12:52                                       ` Christian Aichinger
2005-09-22 14:31                                   ` Timo Hoenig
2005-09-23 23:36                           ` [PATCH] acpi: Fix oops in asus_acpi.c on Samsung P30/P35 Laptops Christian Aichinger
2005-06-29 16:09 oops with asus_acpi on P30/P35 Moore, Robert
     [not found] ` <971FCB6690CD0E4898387DBF7552B90E01F61BCB-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2005-06-29 16:35   ` Karol Kozimor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050921150851.GU22403@orest.greek0.net \
    --to=greek0-hi6y0cq0ng0@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=c-d.hailfinger.devel.2005-hi6Y0CQ0nG0@public.gmane.org \
    --cc=mail-60OJuG18Xr6zQB+pC5nmwQ@public.gmane.org \
    --cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org \
    --cc=thoenig-dCxI//HcOdFeoWH0uzbU5w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.