linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karol Kozimor <sziwan@hell.org.pl>
To: Christian Aichinger <Greek0@gmx.net>
Cc: Linus Torvalds <torvalds@osdl.org>, Hanno B??ck <mail@hboeck.de>,
	Andrew Morton <akpm@osdl.org>,
	acpi-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	"Brown, Len" <len.brown@intel.com>
Subject: Re: [PATCH] Work around asus_acpi driver oopses on Samsung P30s and the like due to the ACPI implicit return
Date: Fri, 23 Dec 2005 13:19:23 +0100	[thread overview]
Message-ID: <20051223121923.GA12918@hell.org.pl> (raw)
In-Reply-To: <20051223113347.GA20475@orest.greek0.net>

Thus wrote Christian Aichinger:
> > Here it goes. Rediffed, also plugs a leak my previous patch introduced. I
> > believe it addresses Linus' comments. It's still not a proper fix (see
> > below), but I believe it's better than none.
> > Best regards,
> This will break other hardware as the P30/P35 as well, since there
> are some buggy DSDT's out there that return an ACPI_TYPE_BUFFER.

I've never seen one, I'd like to look at those if you've got them. Are you
sure it's the actual machine code that returns buffers, and not an implicit
return of the interpreter?

> That's the whole reason why I was testing exactly for
> ACPI_TYPE_INTEGER in my patch.

I don't really seem to follow: my logic checks for ACPI_TYPE_STRING, and if
not found, looks at DSDT signatures. If something different than a string
is returned by INIT _and_ the machine isn't a P30/P35 (DSDT sigs) then the
defaults are set as in every other case a machine is not recognized by the
driver.

> My first version was pretty simmilar to yours, until I was told on
> acpi-devel that this breaks someone elses hardware (causing it to be
> considered as P30/P35, while it isn't). I can dig up the mails if
> you want.

The original driver behaviour was: ( if INIT returns NULL && DSDT sigs
match ) machine is a P30. My patch changes that to ( if INIT returns
!ACPI_TYPE_STRING && DSDT sigs match ) machine is a P30. I'd like to see
those reports please.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

  reply	other threads:[~2005-12-23 12:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 19:06 asus_acpi still broken on Samsung P30/P35 Brown, Len
2005-12-22 10:53 ` Karol Kozimor
2005-12-22 17:42 ` [PATCH] Work around asus_acpi driver oopses on Samsung P30s and the like due to the ACPI implicit return Karol Kozimor
2005-12-23 11:33   ` Christian Aichinger
2005-12-23 12:19     ` Karol Kozimor [this message]
2006-01-16 11:03       ` Hanno Böck
2006-01-17  1:06         ` Karol Kozimor
2006-02-19 12:52   ` Alex Riesen
2006-02-20  5:18     ` Andrew Morton
2006-02-20  9:45       ` Alex Riesen

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=20051223121923.GA12918@hell.org.pl \
    --to=sziwan@hell.org.pl \
    --cc=Greek0@gmx.net \
    --cc=acpi-devel@lists.sourceforge.net \
    --cc=akpm@osdl.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail@hboeck.de \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).