summaryrefslogtreecommitdiffstats
path: root/sys/kern/subr_hints.c
diff options
context:
space:
mode:
authorjhb <jhb@FreeBSD.org>2002-11-22 18:11:13 +0000
committerjhb <jhb@FreeBSD.org>2002-11-22 18:11:13 +0000
commit5e7f195b7c2d3ed9163a4ec3c0e90b569651b56f (patch)
tree9d22c7407abc0aec2196019c2472a159313b86a5 /sys/kern/subr_hints.c
parentc532e9c1042c4729b06bc8853da88a03a269625e (diff)
downloadFreeBSD-src-5e7f195b7c2d3ed9163a4ec3c0e90b569651b56f.zip
FreeBSD-src-5e7f195b7c2d3ed9163a4ec3c0e90b569651b56f.tar.gz
According to the ACPI spec, the bus number of the child PCI bus of a host
to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
Diffstat (limited to 'sys/kern/subr_hints.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud