If I can not bit twiddle at INIT, the majority of lame BIOSes will crash
many systems in the worst way. Understand that the new ATA-66 stuff
requires that one test for cable presence, verify that the device accepts
and acknoledges this state, and finally allow the OS to continue in the
setup. This gets much worse when a vender retains the vender:device ids
and you have to hunt for the host-host or isa-bridge; however, the nastier
ones requires one to dork with other pci devices in the various chipset
combinations to even enable features.
SiS5513 is minor case, I only need to know that which host-host is present.
Via82c586 may approach the level of the Ali15x3 designs.
Ali15x3 is the only current case that requires one to tinker with another
device for setup.
Intel PIIX's are fairly clean. As are a few others.
The Promise Ultra Series requires excessive setup if more than two cards
are used. In all cases tested to date, the third/fourth/fifth card can
only be setup with brut force by the kernel.
HighPoints latest chipset HPT366 appears to suffer this also, based upon
reports but not verified. The HPT343/345 versions forget to setup the
lower for IO address spaces in the config.
So back to the original issue, I have to have access to the PCI config
space at init and the ablity to update of the pci-config data. Some of
this is for setup, as stated above, while other places are needed in a
read-only mode for feature detection.
May be I am missing something here. Are we discussing the PCI config
status after PCI probing is completed? Or are we at the entry point for
the device sub-systems?
Andre Hedrick
The Linux IDE guy
On Tue, 31 Aug 1999, David S. Miller wrote:
>
> Martin, only one minor nit. You cannot allow drivers to arbitrarily
> change resource values _without_ updating the resource tree. In fact
> this kind of stuff was #if 0'd out in the bttv.c driver for example.
>
> We need to either provide an interface to allow a driver to do this,
> or remove all such instances as the PCI probing boot code should be
> setting these things properly.
>
> Later,
> David S. Miller
> davem@redhat.com
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/