From owner-acpi-jp@jp.FreeBSD.org Mon Oct  7 04:30:38 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g96JUc822539;
	Mon, 7 Oct 2002 04:30:38 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g96JUZ322534
	for <acpi-jp@jp.freebsd.org>; Mon, 7 Oct 2002 04:30:36 +0900 (JST)
	(envelope-from msmith@freebsd.org)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g96JUYi26667
	for <acpi-jp@jp.freebsd.org>; Sun, 6 Oct 2002 12:30:34 -0700 (PDT)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5dc6181420118064e13d4@mailgate1.apple.com> for <acpi-jp@jp.freebsd.org>;
 Sun, 6 Oct 2002 12:30:25 -0700
Received: from freebsd.org (vpn-scv-x0-132.apple.com [17.219.192.132])
	by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g96JUXb16704
	for <acpi-jp@jp.FreeBSD.org>; Sun, 6 Oct 2002 12:30:33 -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: <200210052333.IAA27963@axe-inc.co.jp>
Message-Id: <144BF75C-D962-11D6-9E7B-0050E4660701@freebsd.org>
X-Mailer: Apple Mail (2.546)
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Sun, 6 Oct 2002 12:30:32 -0700
X-Sequence: acpi-jp 1882
Subject: [acpi-jp 1882] 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 Saturday, October 5, 2002, at 04:33 PM, Takanori Watanabe 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.
>
> PCI Bus number is *NOT* encoded in _ADR value.

It can be; the spec allows for it, and I believe that I've seen it
in the wild.

> Device and Function number only. Bus number of ACPI pci device object
> should be identified via parent device object.

This is what I said above.  It's specific to PCI devices, and should
not be used to infer that the ACPI tree will resemble any given
operating system's device tree.

> Bus number object
> is _BBN and it only appears in multipule host pci bridge system.

That's not strictly correct.  _BBN should be present when the BIOS
bus number cannot otherwise be determined; again, the ACPI principle
that information that's not available elsewhere should come from
ACPI.

In practice, _BBN is often present on single-host-bridge systems.
It's also often *wrong* on multiple-host-bridge systems, and _ADR
is abused on those systems to indicate the bus number, or to locate
the host-pci bridge in configuration space (it would seem) so that
the bus number can be read from that.

> It is the very reason that device tree should reflect ACPI device
> tree. ACPI object for pci device on pci-pci bridge only identified
> via namespace topology.

There's no need for the device tree to resemble the ACPI namespace
at all.  A PCI device in ACPI namespace results in a triple of
bus/device/function which can then be matched with the same triple
from the device tree without the two resembling each other at all.

  = Mike

