freebsd-nq/sys/dev/acpica/acpi_pcib.c

205 lines
5.9 KiB
C
Raw Normal View History

/*-
* Copyright (c) 2000 Michael Smith
* Copyright (c) 2000 BSDi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include "opt_acpi.h"
#include <sys/param.h>
#include <sys/bus.h>
#include <sys/malloc.h>
#include <sys/kernel.h>
#include "acpi.h"
#include <dev/acpica/acpivar.h>
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
#include <dev/acpica/acpi_pcibvar.h>
#include <dev/pci/pcivar.h>
#include "pcib_if.h"
/* Hooks for the ACPI CA debugging infrastructure. */
#define _COMPONENT ACPI_BUS
ACPI_MODULE_NAME("PCI")
- Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. - Make it possible to turn off selective debugging flags or layers by listing them in debug.acpi.layer or debug.acpi.level prefixed with !. - Fully implement support for avoiding nodes in the ACPI namespace. Nodes may be listed in the debug.acpi.avoid environment variable; these nodes and all their children will be ignored (although still scanned over) by ACPI functions which scan the namespace. Multiple nodes can be specified, separated by whitespace. - Implement support for selectively disabling ACPI subsystem components via the debug.acpi.disable environment variable. The following components can be disabled: o bus creation/scanning of the ACPI 'bus' o children attachment of children to the ACPI 'bus' o button the acpi_button control-method button driver o ec the acpi_ec embedded-controller driver o isa acpi replacement of PnP BIOS for ISA device discovery o lid the control-method lid switch driver o pci pci root-bus discovery o processor CPU power/speed management o thermal system temperature detection and control o timer ACPI timecounter Multiple components may be disabled by specifying their name(s) separated by whitespace. - Add support for ioctl registration. ACPI subsystem components may register ioctl handlers with the /dev/acpi generic ioctl handler, allowing us to avoid the need for a multitude of /dev/acpi* control devices, etc.
2000-12-08 09:16:20 +00:00
ACPI_SERIAL_DECL(pcib, "ACPI PCI bus methods");
/*
* For locking, we assume the caller is not concurrent since this is
* triggered by newbus methods.
*/
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
int
acpi_pcib_attach(device_t dev, ACPI_BUFFER *prt, int busno)
{
device_t child;
ACPI_STATUS status;
- Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. - Make it possible to turn off selective debugging flags or layers by listing them in debug.acpi.layer or debug.acpi.level prefixed with !. - Fully implement support for avoiding nodes in the ACPI namespace. Nodes may be listed in the debug.acpi.avoid environment variable; these nodes and all their children will be ignored (although still scanned over) by ACPI functions which scan the namespace. Multiple nodes can be specified, separated by whitespace. - Implement support for selectively disabling ACPI subsystem components via the debug.acpi.disable environment variable. The following components can be disabled: o bus creation/scanning of the ACPI 'bus' o children attachment of children to the ACPI 'bus' o button the acpi_button control-method button driver o ec the acpi_ec embedded-controller driver o isa acpi replacement of PnP BIOS for ISA device discovery o lid the control-method lid switch driver o pci pci root-bus discovery o processor CPU power/speed management o thermal system temperature detection and control o timer ACPI timecounter Multiple components may be disabled by specifying their name(s) separated by whitespace. - Add support for ioctl registration. ACPI subsystem components may register ioctl handlers with the /dev/acpi generic ioctl handler, allowing us to avoid the need for a multitude of /dev/acpi* control devices, etc.
2000-12-08 09:16:20 +00:00
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
/*
* Don't attach if we're not really there.
*
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
* XXX: This isn't entirely correct since we may be a PCI bus
* on a hot-plug docking station, etc.
*/
if (!acpi_DeviceIsPresent(dev))
- Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. - Make it possible to turn off selective debugging flags or layers by listing them in debug.acpi.layer or debug.acpi.level prefixed with !. - Fully implement support for avoiding nodes in the ACPI namespace. Nodes may be listed in the debug.acpi.avoid environment variable; these nodes and all their children will be ignored (although still scanned over) by ACPI functions which scan the namespace. Multiple nodes can be specified, separated by whitespace. - Implement support for selectively disabling ACPI subsystem components via the debug.acpi.disable environment variable. The following components can be disabled: o bus creation/scanning of the ACPI 'bus' o children attachment of children to the ACPI 'bus' o button the acpi_button control-method button driver o ec the acpi_ec embedded-controller driver o isa acpi replacement of PnP BIOS for ISA device discovery o lid the control-method lid switch driver o pci pci root-bus discovery o processor CPU power/speed management o thermal system temperature detection and control o timer ACPI timecounter Multiple components may be disabled by specifying their name(s) separated by whitespace. - Add support for ioctl registration. ACPI subsystem components may register ioctl handlers with the /dev/acpi generic ioctl handler, allowing us to avoid the need for a multitude of /dev/acpi* control devices, etc.
2000-12-08 09:16:20 +00:00
return_VALUE(ENXIO);
/*
* Get the PCI interrupt routing table for this bus. If we can't
* get it, this is not an error but may reduce functionality.
*/
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
prt->Length = ACPI_ALLOCATE_BUFFER;
status = AcpiGetIrqRoutingTable(acpi_get_handle(dev), prt);
if (ACPI_FAILURE(status))
device_printf(dev,
"could not get PCI interrupt routing table for %s - %s\n",
acpi_name(acpi_get_handle(dev)), AcpiFormatException(status));
/*
* Attach the PCI bus proper.
*/
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
if ((child = device_add_child(dev, "pci", busno)) == NULL) {
device_printf(device_get_parent(dev), "couldn't attach pci bus\n");
- Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. - Make it possible to turn off selective debugging flags or layers by listing them in debug.acpi.layer or debug.acpi.level prefixed with !. - Fully implement support for avoiding nodes in the ACPI namespace. Nodes may be listed in the debug.acpi.avoid environment variable; these nodes and all their children will be ignored (although still scanned over) by ACPI functions which scan the namespace. Multiple nodes can be specified, separated by whitespace. - Implement support for selectively disabling ACPI subsystem components via the debug.acpi.disable environment variable. The following components can be disabled: o bus creation/scanning of the ACPI 'bus' o children attachment of children to the ACPI 'bus' o button the acpi_button control-method button driver o ec the acpi_ec embedded-controller driver o isa acpi replacement of PnP BIOS for ISA device discovery o lid the control-method lid switch driver o pci pci root-bus discovery o processor CPU power/speed management o thermal system temperature detection and control o timer ACPI timecounter Multiple components may be disabled by specifying their name(s) separated by whitespace. - Add support for ioctl registration. ACPI subsystem components may register ioctl handlers with the /dev/acpi generic ioctl handler, allowing us to avoid the need for a multitude of /dev/acpi* control devices, etc.
2000-12-08 09:16:20 +00:00
return_VALUE(ENXIO);
}
/*
* Now go scan the bus.
*/
acpi_pci_link_config(dev, prt, busno);
return_VALUE (bus_generic_attach(dev));
}
int
acpi_pcib_resume(device_t dev)
{
acpi_pci_link_resume(dev);
return (bus_generic_resume(dev));
}
/*
* Route an interrupt for a child of the bridge.
*/
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
int
acpi_pcib_route_interrupt(device_t pcib, device_t dev, int pin)
{
struct acpi_prt_entry *entry;
int i, interrupt;
struct acpi_pci_link_entry *link;
ACPI_PCI_ROUTING_TABLE *prt;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
interrupt = PCI_INVALID_IRQ;
/* ACPI numbers pins 0-3, not 1-4 like the BIOS. */
pin--;
ACPI_SERIAL_BEGIN(pcib);
/* Look up the PRT entry for this device. */
entry = acpi_pci_find_prt(pcib, dev, pin);
if (entry == NULL) {
device_printf(pcib, "no PRT entry for %d.%d.INT%c\n", pci_get_bus(dev),
pci_get_slot(dev), 'A' + pin);
goto out;
}
prt = &entry->prt;
link = entry->pci_link;
if (bootverbose) {
device_printf(pcib, "matched entry for %d.%d.INT%c",
pci_get_bus(dev), pci_get_slot(dev), 'A' + pin);
if (prt->Source[0] != '\0')
printf(" (src %s)", acpi_name(entry->prt_source));
printf("\n");
}
/*
* If source is empty/NULL, the source index is a global IRQ number
* and it's hard-wired so we're done.
*/
if (prt->Source == NULL || prt->Source[0] == '\0') {
if (bootverbose)
device_printf(pcib, "slot %d INT%c hardwired to IRQ %d\n",
pci_get_slot(dev), 'A' + pin, prt->SourceIndex);
if (prt->SourceIndex)
interrupt = prt->SourceIndex;
else
device_printf(pcib, "error: invalid hard-wired IRQ of 0\n");
goto out;
}
/* XXX Support for multiple resources must be added to the link code. */
if (prt->SourceIndex) {
device_printf(pcib, "src index %d not yet supported\n",
prt->SourceIndex);
goto out;
}
/* There has to be at least one interrupt available. */
if (link->number_of_interrupts == 0) {
device_printf(pcib, "device has no interrupts\n");
goto out;
}
/*
* If the current interrupt has been routed, we're done. This is the
* case when the BIOS initializes it and we didn't disable it.
*/
if (link->flags & ACPI_LINK_ROUTED) {
interrupt = link->current_irq;
if (bootverbose)
device_printf(pcib, "slot %d INT%c is already routed to irq %d\n",
pci_get_slot(dev), 'A' + pin, interrupt);
goto out;
}
if (bootverbose) {
device_printf(pcib, "possible interrupts:");
for (i = 0; i < link->number_of_interrupts; i++)
printf("%3d", link->interrupts[i]);
printf("\n");
}
/*
* Perform the link routing. The link code will pick the best IRQ
* for this pin and configure it.
*/
interrupt = acpi_pci_link_route(dev, entry);
if (bootverbose && PCI_INTERRUPT_VALID(interrupt))
device_printf(pcib, "slot %d INT%c routed to irq %d via %s\n",
pci_get_slot(dev), 'A' + pin, interrupt,
acpi_name(entry->prt_source));
out:
ACPI_SERIAL_END(pcib);
return_VALUE (interrupt);
}