> On Wed, 24 Sep 1997, Gerard Roudier wrote:
>
> > 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.
There is no problem at all when things are done as they shall be done.
A conformant 'PCI read config dword' function will return SUCCESSFUL or
BAD_REGISTER NUMBER when it used used correctly for the simple reason
that it is the only value it is required to return. (PCI BIOS 2.1 specs).
Note that 'PCI read config byte' is only required to return SUCCESSFULL.
There is no problem when these functions are used with _existing_ devices
as they must be.
When these functions are called for non existing devices, they are allowed
to behave as they want. Any implementation that would reboot the machine
in such a situation the machine would be quite correct.
> > 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).
Remember that a BIOSes have been specified for hidding HW.
The only allowed way to _really_ generate PCI configuration accesses on
PC architecture is to use a configuration access mechanism.
> > 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
Good practice is to adhere to specifications when they exists.
> 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.
Expecting any special behaviour of PCI BIOS config read functions for a
not present device is similar to expecting your car to fly as a jet.
They just have not been designed to be used this way.
Gerard.