operation with address 0 length 0, which, according to the SCSI-2 spec, should
be interpreted as "synchronize all remaining blocks beginning at address 0".
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...)
