and see if anything responds. if nothing (that's attributable to the
PCI IDE controller) responds, then that channel either has no devices on
it or has been disabled (via a non-standard mechanism) by the BIOS. If nothing
responds, don't map the compat.-mode interrupt or attach the wdc to that
channel, because the BIOS is likely to assign that IRQ to a different PCI
device. If that happens, the kernel will panic because that device will
try to map the IRQ level-triggered, but the compat interrupt will have been
mapped edge-triggered. (One possible way around this is to map the compat
interrupt edge-triggered, but it's not clear reading the spec that this
is correct or desirable.)
and not in d where it goes back to use the eeprom method. So we detect
when the tuple method fails and fall back to the original method.
- even more 3c562 magic; the updated linux driver mentions that addresses
0x??00-0x??7f only work instead of the previous...
- fix debugging code so that it compiles
- reorder the disabling code so that it is more logical
- add splhigh()/splx() in the first establish setting for symmetry
insert a check to see whether a channel appears to be enabled. Shouldn't
be necessary, according to the spec, but some PC chipsets allow individual
compatibility channels to be disabled. "I hate PCs."
two SCC channels, and can get stuck in an infinite loop. This change
stops after flushing 4 bytes. Might need upping to 8 bytes if we support
85230 ESCC's.
Idea bounced off of scottr & gwr
controller driver. These are commented out here until the wdc
declaration mess is resolved, and until then need to go into MD
files files in places where they play nice with the wdc declaration.
entry (because the same product id is used for the 640B, as well). Note
that a few of the entries (PCI0642, PCI0650A) no longer have data to
be found on the CMD web site, and note that PCI0650A should probably have
its "A" trimmed as well.
