[PATCH] IDE 17 (not just cleanup)
This is actually an attempt to remove some stall code from
this driver. However if some *real* users complain (Not just
the usuall: "Hey - if someone!" but the "Hey I'm using this!")
I'm all open to reenable it. Since I prepared this patch
yerstoday it doesn't contain the ide_module.h fixup. This will
- Don't use the convoluted byte type in ide-pci.c. Just use the proper
- Move ide_get_or_set_dma_base to the only place where it's used and
reorganize the code there by killing the unnecessary
CONFIG_BLK_DEV_IDEDMA_FORCED configuration option.
- Remove unfunctional CONFIG_PKT_TASK_IOCTL code.
- Kill unused ALTSTAT_SCREW_UP code.
- Tons of dead code removed from ide-taskfile.c (#if 0 #endif and
- Remove unused IDE_DEBUG macro as well as lots of other name space
pollution from ide.h.
- Start using the ide_lock spin-lock for protecting access to data
structures instead of the excessive interrupt disabling games.
- Shorten the proc ouput of the piix initialization module.
- Remove special /proc tape "name" output from ide-tape.c. This was
redundant data which should only show up on syslog anyway.
- Kill the REALLY_FAST_IO undef from the ide.h. This was a mistake
present since far too many years in this driver. The proper way to
deal with broken systems is to define REALLY_SLOW_IO in system
dependent headers or particular driver files. We can always
reintroduce it easy if real users will complain, since OUT_BYTE() and
similar can be used as hooks. But I don't expect anybody reporting
about this. Even on the most broken IDE chip in the world (cmd640
at VLB) undefining this *always* worked for me. Nearly all the code
pieces in the ide driver code *reverted* it's effects explicitly
- Remove the obsolete CONFIG_BLK_DEV_4DRIVES support. This was supposed
to support 4 drivers attached at one channel on some older chipsets,
in esp. Tekram 690CD, in the last century. They where all supposed to
work at a register set starting at the base address 0x1f0. Before
complaining that this is removing functionality, please note that this
must have been broken for already quite a long time, since the ide
driver didn't contain the special device selection methods implicated
by this any longer. It didn't scan this port too if PCI host chip
support was enabled (as it is in all those distributions around
there). On the other hand this is the most prominent case of
incoherent use of the mate member in the struct hwif_s. And please
think about how big the probability is, that there are systems out
there, where there are actually 4 drivers on such a channel?
- Streamline module initialization code by removing one shoot functions.
- Make the WAIT_READY value used in case of CONFIG_APM or
CONFIG_APM_MODULE the default, since this is what really reflects the
behavior of modern drives. It won't hurt any other case and finally
removing it is reducing the necessary coverage for overall driver code
- Move the IDE_LARGE_SEEK macro to the only place where it's actually
used. Replace the IDE_MIN() and IDE_MAX() drivers with the obvious.
Remove unused SPLIT_WORD and MAKE WORD from the local header.
- Remove CMD640_DUMP_REGS from global scope, since there is no
development done on this any longer. Finally, the way the host chip
initialization routines are called changed in the time between allows
this to remain fully local to the host chip driver in question.
- Some spell checking of comments in the code. (Yeep I have extended my
Vim to do this the "Word" way with nice undercurl lines... mozilla
remains to be fixed...)
28 files changed