From owner-acpi-jp@jp.FreeBSD.org Thu May  8 17:29:10 2003
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id h488TAQ84716;
	Thu, 8 May 2003 17:29:10 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from etek.chalmers.se (_7-12B8@quarl0.etek.chalmers.se [129.16.32.20])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with ESMTP/inet id h488T8Y84709
	for <acpi-jp@jp.FreeBSD.org>; Thu, 8 May 2003 17:29:08 +0900 (JST)
	(envelope-from b@etek.chalmers.se)
Received: from knase19.etek.chalmers.se (postfix@knase19.etek.chalmers.se [129.16.32.39])
	by etek.chalmers.se (8.10.0/8.8.8) with ESMTP id h488SvT19949;
	Thu, 8 May 2003 10:28:57 +0200 (MET DST)
Received: by knase19.etek.chalmers.se (Postfix, from userid 4304)
	id E896CD4DF; Thu,  8 May 2003 10:28:56 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by knase19.etek.chalmers.se (Postfix) with ESMTP
	id DB3E8D4DD; Thu,  8 May 2003 10:28:56 +0200 (CEST)
From: Magnus B{ckstr|m <b@etek.chalmers.se>
To: acpi-jp@jp.FreeBSD.org
Cc: Andrew Thompson <andy@fud.org.nz>, <current@freebsd.org>
In-Reply-To: <200305080526.OAA09382@axe-inc.co.jp>
Message-ID: <Pine.BSF.4.44.0305080930410.2828-100000@knase19.etek.chalmers.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Thu, 8 May 2003 10:28:56 +0200
X-Sequence: acpi-jp 2191
Subject: [acpi-jp 2191] Re: Outstanding ACPI issues for 5.1-RELEASE
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: b@etek.chalmers.se
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+030405

On Thu, 8 May 2003, User Takawata wrote:
>
> That's because the _HID format is not conform to the standard.
> Add following change and check whether Host PCI bus bridge appears or not.

>         !acpi_disabled("pci") &&
> -       acpi_MatchHid(dev, "PNP0A03")) {
> +       acpi_MatchHid(dev, "*PNP0A03")) {
>

I'm afraid this may not be the end of it.  An N800c I encountered a few
weeks ago consistently had _HIDs with asterisks.  If I may contribute
an untested general workaround (untested because I don't currently have
access to the hardware):

Index: src/sys/dev/acpica/acpi.c
diff -u src/sys/dev/acpica/acpi.c:1.1.1.6.2.1 src/sys/dev/acpica/acpi.c:1.1.1.6.2.2
--- src/sys/dev/acpica/acpi.c:1.1.1.6.2.1	Wed Apr 16 16:06:20 2003
+++ src/sys/dev/acpica/acpi.c	Thu May  8 10:00:28 2003
@@ -1041,8 +1041,21 @@
 	return(FALSE);
     if (ACPI_FAILURE(error = AcpiGetObjectInfo(h, &devinfo)))
 	return(FALSE);
-    if ((devinfo.Valid & ACPI_VALID_HID) && !strcmp(hid, devinfo.HardwareId))
-	return(TRUE);
+
+    /*
+     * Some vendors erronously report HIDs with leading asterisks.
+     * The below workaround accomodates this.
+     */
+    if (devinfo.Valid & ACPI_VALID_HID) {
+	    if (devinfo.HardwareId[0] == '*') {
+		    if (strcmp(hid, (devinfo.HardwareId + 1)) == 0)
+			    return TRUE;
+	    }
+
+	    if (strcmp(hid, devinfo.HardwareId) == 0)
+		    return (TRUE);
+    }
+
     if (ACPI_FAILURE(error = acpi_EvaluateInteger(h, "_CID", &cid)))
 	return(FALSE);
     if (cid == PNP_EISAID(hid))


Furthermore, the laptop used idioms that were a bit too modern for
our ACPI implementation.  CIDs are allowed to be not only integers,
but also buffers (think `char *') with images of ACPI_INTEGERs, and
packages with multiple integer objects in them (for multiple possible
CIDs).  The below -should- fix this but is also untested.

Index: src/sys/dev/acpica/acpi.c
diff -u src/sys/dev/acpica/acpi.c:1.1.1.6.2.2 src/sys/dev/acpica/acpi.c:1.1.1.6.2.3
--- src/sys/dev/acpica/acpi.c:1.1.1.6.2.2	Thu May  8 10:00:28 2003
+++ src/sys/dev/acpica/acpi.c	Thu May  8 10:06:17 2003
@@ -1160,20 +1160,57 @@
 {
     ACPI_OBJECT	*p;
     int		i;
+    ACPI_INTEGER num;

     p = (ACPI_OBJECT *)bufp->Pointer;
     if (p->Type == ACPI_TYPE_INTEGER) {
 	*number = p->Integer.Value;
 	return(AE_OK);
     }
-    if (p->Type != ACPI_TYPE_BUFFER)
+    if (p->Type == ACPI_TYPE_PACKAGE) {
+	/*
+	 * Shrewdly guess that the vendor is likely to put the most
+	 * useful element last in the package.
+	 */
+	if (p->Package.Elements[p->Package.Count-1].Type ==ACPI_TYPE_INTEGER) {
+	    *number = (int) p->Package.Elements[1].Integer.Value;
+	    return (AE_OK);
+	}
+
+    }
+    if (p->Type != ACPI_TYPE_BUFFER) {
+	printf("acpi_ConvertBufferToInteger: Unknown p->Type %d\n", p->Type);
 	return(AE_TYPE);
-    if (p->Buffer.Length > sizeof(int))
-	return(AE_BAD_DATA);
-    *number = 0;
-    for (i = 0; i < p->Buffer.Length; i++)
-	*number += (*(p->Buffer.Pointer + i) << (i * 8));
-    return(AE_OK);
+    }
+
+    /*
+     * In ACPI 2.0 an ACPI_INTEGER is 64 bit.  In 1.0 it was 32 bit.
+     * We comply with either.
+     */
+    if (p->Buffer.Length == sizeof(ACPI_INTEGER)) {
+	num = 0;
+
+	for (i = 0; i < p->Buffer.Length; i++)
+	    num += (*(p->Buffer.Pointer + i) << (i * 8));
+
+	*number = (int) num;
+	return(AE_OK);
+    }
+
+    /* ACPI 1.0 case. */
+    if (p->Buffer.Length == sizeof(int)) {
+	*number = 0;
+
+	for (i = 0; i < p->Buffer.Length; i++)
+	    *number += (*(p->Buffer.Pointer + i) << (i * 8));
+
+	return (AE_OK);
+    }
+
+    printf("acpi_ConvertBufferToInteger: bad buffer length %d\n",
+	   p->Buffer.Length);
+
+    return (AE_BAD_DATA);
 }

 /*


Best regards,
Magnus

