From owner-acpi-jp@jp.freebsd.org  Tue Oct 10 02:29:03 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id CAA71451;
	Tue, 10 Oct 2000 02:29:03 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id CAA71445;
	Tue, 10 Oct 2000 02:29:01 +0900 (JST)
	(envelope-from andrew.grover@intel.com)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id KAA22246;
	Mon, 9 Oct 2000 10:28:54 -0700 (PDT)
Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 09 Oct 2000 17:28:53 0000 (GMT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <4LBPKKT9>; Mon, 9 Oct 2000 10:28:52 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E8905DE3B6@orsmsx35.jf.intel.com>
From: "Grover, Andrew" <andrew.grover@intel.com>
To: "'Mitsuru IWASAKI'" <iwasaki@jp.FreeBSD.org>
Cc: acpi-jp@jp.FreeBSD.org
Date: Mon, 9 Oct 2000 10:28:44 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 844
Subject: [acpi-jp 844] RE: Another ACPICA workaround: default return value
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: andrew.grover@intel.com

This is noncompliant AML, but Windows' acpi driver (apparently by accident)
allows it, so it hasn't been fixed.

So yes, we know about it, but we're still determining what's the right thing
to do long term. Short-term, this workaround certainly seems appropriate.

Regards -- Andy

> -----Original Message-----
> From: Mitsuru IWASAKI [mailto:iwasaki@jp.FreeBSD.org]
> Sent: Sunday, October 08, 2000 11:02 PM
> To: andrew.grover@intel.com
> Cc: acpi-jp@jp.FreeBSD.org
> Subject: Another ACPICA workaround: default return value
> 
> 
> Hi, Andrew
> 
> I've noticed that some method caller expects return value without
> explicit ReturnOp in some AML code.  Here is example ASL of TOSHIBA
> Portege 3110CT.
> 
> Scope(\_SB) {
>     Device(LNKA) {
>         Name(_HID, 0xf0cd041)
>         Name(_UID, 0x1)
>         Method(_STA) {
>             STAL(0x60)		<----------- this one.
>         }
> 		:
> Method(STAL, 1) {
>     Store(Arg0, \_SB.MEM.IEDI)
>     SMBR(0xfe00, 0x38b108, 0x0, 0x0, 0xb2)
>     If(LEqual(\_SB.MEM.OECX, 0x80)) {
>         Return(0x9)
>     }
>     Else {
>         Return(0xb)
>     }
> }
> 
> I couldn't find the description how we should treat this in ACPI spec,
> but I guess that above code expects the method (_STA) should 
> return the
> last evaluated value (return value from STAL) if the method doesn't
> have ReturnOp like other programming languages (e.g. perl).
> I've just made a patch for this by quick hack, but I'm not sure this
> is a right solution because I'm not familiar with ACPICA parser yet.
> Could you review this patch?

