2 reasons:
-no need to keep a list of all known parts
-there is at least 1 bridge (ACC micro 2051) which reports the same
device ID for its various subfunctions; this would require an additional
check in the match function
(keep the old list inside #if 0 in case one of the historical bridges
doesn't report the right class/subclass - I can't check them all)
and i/o enabled) should be passed to the primary PCI bus's autconfiguration
node. Use this function to detect broken PCI-Host bridges, which have
problems with memory-mapped access. Add the SIS 85C496 to this list.
primarily to nicely print version information about your PCI chipset
(try with "options PCIVERBOSE"). Eventually, it may be used to
enable/disable features/bugs of a given PCI chipset. In addition, this
driver uses the PCI-ISA bridge callback mechanism to logically attach the
ISA bus to the PCI-ISA bridge.
driver is a place-holder, which will nicely print version information
about your PCI chipset (try with "options PCIVERBOSE"). Eventually,
this can be used to enable/disable features/bugs of individual PCI
chipsets.
- No more distinction between i/o-mapped and memory-mapped
devices. It's all "bus space" now, and space tags
differentiate the space with finer grain than the
bus chipset tag.
- Add memory barrier methods.
- Implement space alloc/free methods.
- Implement region read/write methods (like memcpy to/from
bus space).
This interface provides a better abstraction for dealing with
machine-independent chipset drivers.
(soon to be documented on mailing lists; eventually in section 9 manual
pages), most importantly:
(1) support interrupt pin swizzling on non-i386 systems with
PCI-PCI bridges (per PPB spec; done, but meaningless, on i386).
(2) provide pci_{io,mem}_find(), to determine what I/O or memory
space is described by a given PCI configuration space
mapping register.
(3) provide pci_intr_map(), pci_intr_string(), and
pci_intr_{,dis}establish() to manipulate and print info about
PCI interrupts.
(4) deprecate the pci_map_* functions, and provide them only
as compatibility interfaces (in pci_compat.c) which will
eventually go away, implemented as wrappers around
the functions described above.
(5) make pci functions take as an argument a machine-dependent
cookie, to allow more flexibility in implementation.
enami