to compile. I made the changes that seemed to make sense tracking the
shift from TS_WOPEN to tp->t_wopen- but they may be wrong. I wasn't
subscribed to tech-kern so I missed the discussion, and C. Hannum
was not particularly enlightening. Sorry if this isn't quite right.
ID) when determining if the Vendor ID is invalid. The spec says that
Vendor ID of 0xffff is invalid, so, it doesn't _matter_ what the product
ID is in that case. Treat Vendor ID 0 as invalid because we always have.
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
