From owner-acpi-jp@jp.freebsd.org  Fri Oct 13 07:00:09 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id HAA64486;
	Fri, 13 Oct 2000 07:00:09 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id HAA64480;
	Fri, 13 Oct 2000 07:00:04 +0900 (JST)
	(envelope-from andrew.grover@intel.com)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.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 WAA26247;
	Thu, 12 Oct 2000 22:01:17 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 12 Oct 2000 21:59:58 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <4M7PJFBA>; Thu, 12 Oct 2000 14:59:57 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E8905DE3DE@orsmsx35.jf.intel.com>
From: "Grover, Andrew" <andrew.grover@intel.com>
To: "'Mitsuru IWASAKI'" <iwasaki@jp.FreeBSD.org>
Cc: "'acpi-jp@jp.FreeBSD.org'" <acpi-jp@jp.FreeBSD.org>
Date: Thu, 12 Oct 2000 14:59:49 -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 863
Subject: [acpi-jp 863] 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

It looks like we will not be adding a workaround for this. This is
non-compliant AML. We view being bug-for-bug compatible with Microsoft as a
losing proposition -- we will implement to the spec, not MS.

That said, I know you all need working machines, so patch away. ;-) I would
hope that when you do, the code doesn't just accept this and move on, but
emits a warning to the user, or something.

Regards -- Andy

> -----Original Message-----
> From: Grover, Andrew 
> Sent: Monday, October 09, 2000 10:29 AM
> To: 'Mitsuru IWASAKI'
> Cc: acpi-jp@jp.FreeBSD.org
> Subject: RE: Another ACPICA workaround: default return value
> 
> 
> 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?
> 

