a struct device * corresponding to the ISA bus device. The ISA DMA
controller driver functions have been renamed and now take a struct
isa_dma_state *, and are called indirectly by machine-dependent code
which provides the DMA state.
These changes allow e.g. `ofisa' (the OpenFirmware configuration
mechanism for the ISA bus, used by e.g. Sharks) to use the MI ISA
DMA controller code.
- When there is only one pcmcia function, don't use first config
entry to determine card type. Instead, use the config entry
actually used to initialize the pcmcia function if it is already
initialized, else a card is memory-type.
- Don't put a space after cast.
- Use SIMPLEQ_FIRST/NEXT macro.
used in the SMC EtherPower II.
Media control isn't yet supported, due to some MII infrastructure
problems which I hope to address soon. This isn't a huge deal, since
the PHY defaults to auto-negotiate mode.
Also, the device just programs the multicast hash table to accept all
multicast, to avoid a hardware bug that causes the multicast address
filter to lose in 10Mb/s mode. This bug will be fixed in a more sane
way once the media control issues are dealt with.
of last resort when trying to communicate information about
bogus behaviour of PCI devices to the MI autoconfiguration code.
In general, bogus behaviour should be handled by drivers, but there
are some types of bogons which can't be addressed that way. The
only quirk currently defined is one which indicates that the device
is multi-function even though the device's header says otherwise.
(Mmm, Intel 82371FB PCI-to-ISA Bridge (PIIX); you'd think that at least
Intel would have gotten it right...)
of functions on a given device. Also, clean up the #if 0'd
major-debugging-spew code so that it's all one piece, so that
it's a bit prettier, and so that it prints out quirk information.
of last resort when trying to communicate information about
bogus behaviour of PCI devices to the MI autoconfiguration code.
In general, bogus behaviour should be handled by drivers, but there
are some types of bogons which can't be addressed that way. The
only quirk currently defined is one which indicates that the device
is multi-function even though the device's header says otherwise.
(Mmm, Intel 82371FB PCI-to-ISA Bridge (PIIX); you'd think that at least
Intel would have gotten it right...)
printing into a function, add a bit more pretty-printing of existing stuff.
Implement pretty-printers for type 1 and type 2 headers. (Right now,
these are just quick stabs based on some on-line bridge docs that I have
handy on my laptop. Mmmm, meetings. I'll check the bits when I get
back within reach of my official docs.)
release the first 96 bits of the hash directly rather than by folding.
The full 160 bit hash is mixed back into the entropy pool. This keeps
64 bits secret to stir the pool with.
lots of data, e.g. ~18k on a PCI system with few add-in devices; use
with MSGBUFSIZE=...). Useful to have here so that people who want as
much data about the PCI configuration in a machine can get it without
having to craft their own code. Also, clean up a few of the other
#if 0'd printfs.
* print all configuration space registers. Then, where possible,
interpret them. (That is, PRESENT ALL THE DATA, then interpret it --
don't hide data behind interpretation. Also, when interpreting
fields, try to print out the specific value that's being interpreted.)
* handle different header types.
* allow caller to specify a function which can interpret the
device-dependent header and is responsible for pretty-printing it.
It spews (use 'options MSGBUFSIZE=...' 8-), but when you want the data,
you really want _all_ of it.
Still needs some cleanup and additional code (e.g. interepretation
of PCI-PCI (type 1) and PCI-Cardbus (type 2(?)) bridge headers).
pci_mapreg_info() call. pci_mapreg_map() implies this check,
but code which calls pci_mapreg_info() has to check it explicitly.
Otherwise, if memory space is disabled, the driver does the wrong
thing, and tries to use memory space anyway, potentially resulting
incorrect driver operation and no useful error message.
The graphics device driver passes a "default attribute" for normal text
output to the wscons framework. If the emulation module needs more
attributes (for different "renditions") it can allocate them via a
callback.
For now, only the "sun" emulation makes use of it.
problem was. A collision between a select and reselect would leave TC
non-zero from the command-out DMA count, which could later be considered
a fatal condition, causing a reboot. The message for that error was
only displayed with DEBUG. Fixed by clearing TC on a reselect. The
non-zero TC detection won't occur in this case, so unconditionally
display the message if it occurs.
Workaround for another problem that resulted from an "Illegal Command"
status from the 53c94 which would get ignored and result in a timeout
(which also reboots the system). Added the missing check for the
illegal command status, and add the workaround of resending the "accept
message" command to the 53c94. Correct fix will be to determine why the
message wasn't sent in the first place. Abort if the resending the
command doesn't work.
Correctly detect a spurious interrupt and ignore it. This was taken
from a newer Mach driver, but did not get the check converted for the
design difference between the current NetBSD driver and the Mach driver.
it implemented under the label `shortcut:' and only use it in these
cases: (1) after successful re-relection, (2) after receiving command-complete
status, and (3) during message-in handshake.