From owner-acpi-jp@jp.FreeBSD.org Tue Mar 30 03:24:21 2004
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id i2TIOLb99793;
	Tue, 30 Mar 2004 03:24:21 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with ESMTP/inet id i2TIOJd99776
	for <acpi-jp@jp.FreeBSD.org>; Tue, 30 Mar 2004 03:24:19 +0900 (JST)
	(envelope-from robert.moore@intel.com)
Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7])
	by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i2TISMq4010904;
	Mon, 29 Mar 2004 18:28:23 GMT
Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54])
	by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i2TIFi9Q013750;
	Mon, 29 Mar 2004 18:16:16 GMT
Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60])
 by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004032910231518621
 ; Mon, 29 Mar 2004 10:23:15 -0800
Received: from orsmsx403.amr.corp.intel.com ([192.168.65.209]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 29 Mar 2004 10:23:15 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Message-ID: <37F890616C995246BE76B3E6B2DBE0552D0666@orsmsx403.jf.intel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [acpi-jp 3117] RE: ACPI-CA 20040311 imported
Thread-Index: AcQU3Vf6HpyfpAEeTFulcqBuxNdGHQA3S0Lg
From: "Moore, Robert" <robert.moore@intel.com>
To: "Bruno Ducrot" <ducrot@poupinou.org>
Cc: "Nate Lawson" <nate@root.org>, <acpi-jp@jp.FreeBSD.org>,
   <current@freebsd.org>
X-OriginalArrivalTime: 29 Mar 2004 18:23:15.0830 (UTC) FILETIME=[E7161160:01C415BA]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Mon, 29 Mar 2004 10:23:15 -0800
X-Sequence: acpi-jp 3159
Subject: [acpi-jp 3159] RE: ACPI-CA 20040311 imported
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: robert.moore@intel.com
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+040307


There's nothing in the ACPI spec that precludes recursive methods.
However, I agree that it is a very scary thing to do.  For this reason,
I have the iASL compiler issue a remark when it detects a recursive
method call.

All AML interpreters that I know of implement nested and recursive
method calls without chewing up the kernel stack, i.e., a state is
allocated for each nested call and linked to the previous method state.

Bob


-----Original Message-----
From: Bruno Ducrot [mailto:ducrot@poupinou.org]=20
Sent: Sunday, March 28, 2004 7:57 AM
To: Moore, Robert
Cc: Nate Lawson; acpi-jp@jp.FreeBSD.org; current@freebsd.org
Subject: Re: [acpi-jp 3117] RE: ACPI-CA 20040311 imported

On Fri, Mar 26, 2004 at 01:52:21PM -0800, Moore, Robert wrote:
> Here's an example of ASL recursion:
>=20
> Method(PWUP,0,NotSerialized)
> {
>     If(LAnd(\_SB.PCI0.CBS0.PWRS,\_SB.PCI0.CBS1.PWRS))
>     {
>         If(LNot(And(_ADR /* \_SB.PCI0.CBS0._ADR */,0xFFFF)))
>         {
>             And(MCTL /* \_SB.PCI0.CBS0.MCTL */,0x7C,Local0)
>             Or(Local0,BMCL /* \_SB.PCI0.CBS0.BMCL */,MCTL /*
> \_SB.PCI0.CBS0.MCTL */)
>         }
>         Else
>         {
>             \_SB.PCI0.CBS0.PWUP()
>         }
>     }
> }

I assume that PWRS are some hardware io (pci conf probably), able to
detect if the cardbus is powered or not.
I assume _ADR can not be made dynamic.  So far, this function look like:

Method(PWUP, 0, NotSerialized) {
	While (Not((LAnd(\_SB.PCI0.CBS0.PWRS,\_SB.PCI0.CBS1.PWRS))) {
		Noop
	}
}
and is probably called from _WAK, or more likely from _PS0 so far I
guess it is ok to busy loop (in both form).

Why not writting the busy loop instead?

In the original form, there is the possibility to crash the system
by overflowing the kernel stack if the bus is not powered quickly.



--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
