From owner-acpi-jp@jp.FreeBSD.org Tue Oct  8 04:41:06 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g97Jf6h40014;
	Tue, 8 Oct 2002 04:41:06 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g97Jf4340007
	for <acpi-jp@jp.FreeBSD.org>; Tue, 8 Oct 2002 04:41:05 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 9679 invoked from network); 7 Oct 2002 19:41:02 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63])
          (envelope-sender <jhb@FreeBSD.org>)
          by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
          for <msmith@freebsd.org>; 7 Oct 2002 19:41:02 -0000
Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1])
	by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id g97Jexn5003181;
	Mon, 7 Oct 2002 15:41:00 -0400 (EDT)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20021007154103.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <XFMail.20021007152303.jhb@FreeBSD.org>
From: John Baldwin <jhb@freebsd.org>
To: acpi-jp@jp.FreeBSD.org
Cc: Michael Smith <msmith@freebsd.org>
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Mon, 07 Oct 2002 15:41:03 -0400
X-Sequence: acpi-jp 1886
Subject: [acpi-jp 1886] RE: acpi-jp@jp.FreeBSD.org
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: jhb@FreeBSD.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+020902


On 07-Oct-2002 John Baldwin wrote:
> On 07-Oct-2002 Michael Smith wrote:
>> 
>> 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 think it is giving us the config space address of the bridge on bus
> 0 which we could then use to read the bus number?  Well, maybe. :(
> According to the Shanley PCI book, Host-PCI bridges aren't required to
> export their configuration registers in config space but may do it in
> I/O or memory mapped I/O space instead.  Perhaps I am misinterpreting it
> though:
> 
> "With the possible exception of the host/PCI bridge, every PCI function
>  must implement PCI configuration space within which its PCI configuration
>  registers reside.  The host/PCI bridge could implement these registers,
>  in PCI configuration space (this is most often the case), in IO space
>  (much too crowded), or in memory space."
> 
> (The "With the ... host/PCI bridge," part at the beginning is supposedly
>  new in the 2.2 spec, this paragraph is taken from the 4th edition of
>  PCI System Architecture page 351.)

So perhaps what we should do is try to read the config registers and if
that fails we are kind of toast.  Well, if it fails we could start walking
the list of child devices to see if any are PCI-PCI bridges and read their
Primary Bus Number but that is really gross.  It doesn't seem that _UID
can be reliably used in this case since _UID is just supposed to be a serial
number.  Do the Intel guys have any input on what to do in this case?

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
