Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If
we are probing a PCI-PCI bridge it is because we found one by enumerating the devices on a PCI bus, so the bridge is definitely present. A few BIOSes report incorrect status (_STA) for some bridges that claimed they were not present when in fact they were. While here, move this check earlier for Host-PCI bridges so attach fails before doing any work that needs to be torn down. PR: kern/91594 Tested by: Jack Vogel @ Intel MFC after: 1 week
This commit is contained in:
parent
ce300fbfb7
commit
8f4c2e526b
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=252576
@ -134,15 +134,6 @@ acpi_pcib_attach(device_t dev, ACPI_BUFFER *prt, int busno)
|
||||
|
||||
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
|
||||
|
||||
/*
|
||||
* Don't attach if we're not really there.
|
||||
*
|
||||
* XXX: This isn't entirely correct since we may be a PCI bus
|
||||
* on a hot-plug docking station, etc.
|
||||
*/
|
||||
if (!acpi_DeviceIsPresent(dev))
|
||||
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. There
|
||||
|
@ -286,6 +286,12 @@ acpi_pcib_acpi_attach(device_t dev)
|
||||
sc->ap_dev = dev;
|
||||
sc->ap_handle = acpi_get_handle(dev);
|
||||
|
||||
/*
|
||||
* Don't attach if we're not really there.
|
||||
*/
|
||||
if (!acpi_DeviceIsPresent(dev))
|
||||
return (ENXIO);
|
||||
|
||||
/*
|
||||
* Get our segment number by evaluating _SEG.
|
||||
* It's OK for this to not exist.
|
||||
@ -353,7 +359,7 @@ acpi_pcib_acpi_attach(device_t dev)
|
||||
if (status != AE_NOT_FOUND) {
|
||||
device_printf(dev, "could not evaluate _BBN - %s\n",
|
||||
AcpiFormatException(status));
|
||||
return_VALUE (ENXIO);
|
||||
return (ENXIO);
|
||||
} else {
|
||||
/* If it's not found, assume 0. */
|
||||
sc->ap_bus = 0;
|
||||
|
Loading…
Reference in New Issue
Block a user