chipset to be probed & attached on newer Dell PowerEdge servers, such as
the 2400 and 4400.
Reviewed by: dfr, msmith, jlemon
Tested by: hnokubi@yyy.or.jp (in a previous incantation)
Approved by: jkh
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
host->pci bridge specifically, then add a pcib0 device on the motherboard
for the pci bus to hang off.
Requested by: Anders Andersson <anders@sanyusan.se>
Obtained from: dfr
as PCI->HOST bridges on my (440BX) box.
My change is to remove the test at the beginning entirely, letting the
switch on the device ID happen first. If the device ID is unknown, then
(in the default case) check for the generic PCIS_BRIDGE_HOST tag. This
should allow wierd cases (eg: wpaul's IMS VL bridge) to work by using the
id override. This strategy is more in line with the other PCI match
methods we use elsewhere,
I only have a limited testbed, but having my USB etc devices detected as
PCI->HOST bridges doesn't look good.
correctly. It has the following code:
if (class != PCIC_BRIDGE || subclass != PCIS_BRIDGE_HOST)
return NULL;
My 486 has an Integrated Micro Solutions PCI bridge which identifies
itself as subclass PCIS_BRIDGE_OTHER, not PCIS_BRIDGE_HOST. Consequently,
it gets ignored. In my opinion, the correct test should be:
if ((class != PCIC_BRIDGE) && (subclass != PCIS_BRIDGE_HOST))
return NULL;
That way the test still succeeds because the chip's class is PCIC_BRIDGE.
Clearly it's not reasonable to expect all host to PCI bridges to always
have a subclass of PCIS_BRIDGE_HOST since I've got one that doesn't.
This way the sanity test should remain relatively sane while still allowing
some oddball yet correct hardware to work. If somebody has a better way
to do it, go ahead and tweak the test, but be aware that
class == PCIC_BRIDGE and subclass == PCIS_BRIDGE_OTHER is a valid case.
While I was here, I also added an explicit ID string for the IMS chipset.
I also dealt with a minor style nit: it's bad karma not to have a default
case for your switch statements, but the one in this routine doesn't have
one. The default string of "Host to PCI bridge" is now assigned in a
default case of the switch statement instead of initializing "s" with the
string before the switch and then not having any default case.
It failed to recognize the PCI bus in a system that had only an
old chip-set (class code 000000) and a Cyclom multiport serial
card on PCI bus 0, but no VGA card or disk or network controller.
PR: i386/5300
Submitted by: Nickolay N. Dudorov <nnd@itfs.nsk.su>
Adjust the data port address by adding the two low order bits of
the register number. The address port takes only a word address
(i.e. ignores the two low order bits written to it).
mode 1. Omission of this bit makes all config register accesses fail in
on recent chip sets ...
(The problem was reported and debug output provided by: Steve Passe)
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
(1) deleted #if 0
pc98/pc98/mse.c
(2) hold per-unit I/O ports in ed_softc
pc98/pc98/if_ed.c
pc98/pc98/if_ed98.h
(3) merge more files by segregating changes into headers.
new file (moved from pc98/pc98):
i386/isa/aic_98.h
deleted:
well, it's already in the commit message so I won't repeat the
long list here ;)
Submitted by: The FreeBSD(98) Development Team
is only used by the icu support modules and by a few drivers that know
too much about the icu (most only use it to convert `n' to `IRQn'). isa.h
is only used by ioconf.c and by a few drivers that know too much about
isa addresses (a few have to, because config is deficient).
#includes to get prototypes.
pci now uses a different interrupt handler type for interrupts that it
dispatches and the isa interrupt handler type for the interrupts that
it handles.
accesses after the BIOS bus scan. The previous revision made the assumption,
that every PCI motherboard did ...
Change the test on the initial value of the CONF1_ADDR_PORT register in a way
that makes the probe succeed on triton based motherboards, without breaking
the EISA motherboard that has some non-PCI register at the same address.
Require the state of the configuration enable bits to be OFF assuming
that the BIOS left them that way, as it should anyway to avoid bad things
to happen.
The tests themselves are copied from the previous release, with the
exception of CONF1_ENABLE_MSK1 having the LSB set. This bit should be
read back as '0', since only DWORD addresses are legal.
Changes relative to 1.12:
- Put extra instruction between outl()/inl() sequence to prevent the
old value being read back because of the bus capacitance.
- Additional check for existence of register at CONF2_ENABLE_PORT.
there is a PCI bus at all) ...
- Do not expect the chip sets to follow even very clearly expressed
requirements of the PCI 2.0 spec.
- Do not read back the value just written to an I/O port without making
sure that some other data have crossed the bus in between ...
fail on new hardware (Compaq Prolinea and Compaq Prosignea), and that
doesn't erroneously identify old mech. 2 chip sets as using mech. 1.
(See section 3.6.4.1.1 of the PCI bus specs rev. 2.0)
