From owner-acpi-jp@jp.FreeBSD.org Tue Oct  8 03:55:16 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g97ItGk32654;
	Tue, 8 Oct 2002 03:55:16 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g97ItE332649
	for <acpi-jp@jp.freebsd.org>; Tue, 8 Oct 2002 03:55:14 +0900 (JST)
	(envelope-from msmith@freebsd.org)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g97ItBs22165
	for <acpi-jp@jp.freebsd.org>; Mon, 7 Oct 2002 11:55:11 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5dcb1e0b28118064e13d4@mailgate1.apple.com> for <acpi-jp@jp.freebsd.org>;
 Mon, 7 Oct 2002 11:55:02 -0700
Received: from freebsd.org (vpn-scv-x4-205.apple.com [17.219.194.205])
	by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g97It8b20825
	for <acpi-jp@jp.FreeBSD.org>; Mon, 7 Oct 2002 11:55:08 -0700 (PDT)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
From: Michael Smith <msmith@freebsd.org>
To: acpi-jp@jp.FreeBSD.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <XFMail.20021006173216.jhb@FreeBSD.org>
Message-Id: <4C8322EE-DA26-11D6-B432-0050E4660701@freebsd.org>
X-Mailer: Apple Mail (2.546)
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Mon, 7 Oct 2002 11:55:08 -0700
X-Sequence: acpi-jp 1884
Subject: [acpi-jp 1884] Re: acpi-jp@jp.FreeBSD.org
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: msmith@freebsd.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+020902


On Sunday, October 6, 2002, at 02:32 PM, John Baldwin wrote:

>> When it comes to matching devices enumerated by means other than
>> ACPI with devices in the ACPI namespace, we're talking about PCI
>> these days and the _ADR resource is adequate as long as the bus
>> number is correct, and ACPI tells us we can get the bus number
>> either from _ADR directly or from the device's scope in the ACPI
>> namespace.
>
> Er, _ADR is just device and function.  The bus is inherit from the
> parent device.

Er, that's what I just *said*.

My point about having to use _ADR in place of _BBN is important
though, since the code in acpi_pci.c isn't right.  It's meant to
deal with cases like this:

Scope(\_SB_) {
     Device(PCI0) {
         Name(_HID, 0x030ad041)
         Name(_UID, 0x0)
         Name(_BBN, 0x0)
         Name(_ADR, 0x1)
...
     Device(PCI1) {
         Name(_HID, 0x030ad041)
         Name(_UID, 0x1)
         Name(_BBN, 0x0)
         Name(_ADR, 0x2)

Where BBN is clearly wrong on the second bus. (Intel KOA platform
ASL).

However, from looking at more ASL I *think* that I came to the
wrong conclusion about what _ADR is meant to mean here.  The
strict interpretation of _ADR can only be made in the scope
of the device's parent, but that would lead you to expect that
it would be the same as _UID in this case.

So is it giving us the PCI config space addresses of the bridges?
The example above has nodes with _ADR 0, 1, 2 and 3 elsewhere as well...

>>> I don't object some ISA-like devices are direct child of acpi bus.
>>> It is  more better that ISA bus children is automatically
>>> child of ACPI-bus children.
>>
>> Are you suggesting we should have an acpi_isab bus that replaces
>> the standard isab and hang the "manually" probed ISA devices off
>> it if there is ACPI in the system?  That works for me.
>
> Well, an ACPI driver for PCI-ISA bridges and an ACPI driver for
> "isa" busses perhaps. :)  This would allow us to cleanly not use
> the PnPBIOS when ACPI is in use for ISA busses.

You don't appear to get it.  There won't be "an ACPI driver for PCI-ISA
bridges" because the PCI-ISA bridge is enumerated in PCI space.  There
*may* be a node for it in the ACPI namespace, but it's not required and
there's no way to identify it if there is (without probing PCI space
and then using _ADR to hook it up, which means you might as well just
have a PCI probe function like we already do).

  = Mike

