> That depends on the way you try to access the confguration space of a
> not present device.
>
> If you use directly the PCI bios (pci_bios_config_read() functions and
> friends) you are just using this function _improperly_.
>
> The behaviour of these functions is only specified for devices that have
> been successfully detected using a configuration mechanism.
And how do you know that there is a device, AFAIK the only way is to
perform a configuration cycle, so it becomes a chicken and egg problem.
Admittedly the code should also check the return code for
pcibios_read_config_dword(...VENDOR_ID...), but I still have to find a
BIOS that returns PCIBIOS_DEVICE_NOT_FOUND in this case.
> So, if the device is not present the returned value is UNPREDICABLE.
Not according to HW specifications, a configuration read to a not present
device terminates with a master abort and returns a value of all ones.
(More complex on non-Intel where it may generates interrupts and machine
checks).
> If you are using a configuration mechanism (#1 or #2) that accesses
> directly the PCI controller, you will normally get the expected value
> 0xffff for not existing PCI devices.
>
>
> Look into the kernel. If the kernel try to use a PCI bios function to
> access the device and this device is not present, you are just assuming
> some extra PCI bios specifications. If it uses a configuration
> mechanism, then the PCI controller is broken.
Perhaps in theory but not in practice, you pass the address of a random
value. Either the BIOS sets an error return code and does not modify the
result, or it does not check and it writes all ones to the return value.
However, in this case the BIOS modifies the return value, and it should be
set 0xffffffff if the device is not present. The fact that only 1 or 2
bits are wrong more likely indicates a hardware problem than anything else.
Gabriel.