Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> So the current plan is to go with an io_delay=udelay default in v2.6.25, 
> to give this a migration window, and io_delay=none in v2.6.26 [and a 
> complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are 
> fixed up. This is gradual enough to notice any regressions we care about 
> and also makes it nicely bisectable and gradual.

You will break systems if you blindly go around disabling _p delays for
ISA and LPC bus devices. The DEC Hinote laptops for example are well
known for requiring the correct ISA and other keyboard controller delays.
I don't expect anyone to test with a hinote or see it until it hits
Debian or similar 'low resource' friendly devices.

A 2.6.26 plan for io_delay=none is very very foolish indeed. We don't burn
the processor manuals, overclock the CPU and use undefined behaviour
hacks, we shouldn't do the same for I/O devices. Your claim of
bisectability is also completely confused and wrong. If, for example, you
write to an SCC without delays then the chances are it will work most
times. Bisecting doesn't work for random timing dependant failures.

We have four categories of _p users

- Devices that don't need it -> Eliminate use
- Old Devices that do need it -> Codify use and fix locking
- Legacy Devices that we don't need to use on modern systems -> Avoid use
- Devices that sometimes need it -> Evaluate options

There is absolutely no point in breaking, overclocking and introducing
random unreliabilities (that may be stepping or even device instance
specific) into device drivers. Quite the reverse in fact - the way to
drive out _p misuse for debugging is to make it *very* visible. An
io_delay=debug which beeps the keyboard buzzer each _p access will be
most informative and lead to far better and correct debugging.

The components in question for the typical user of a modern system are:
	ISA DMA controller (doesn't get used)
	Keyboard interface (notoriously sensitive to timing, going USB)
	PIC (use the APIC instead)
	Legacy Timers (use the newer timers instead)
	CMOS (slow as **** anyway so udelay 2 doesn't matter)
	Floppy (dying out and slow anyway)

So there is nothing to gain from going with "No delay" and everything to
lose. What we actually want to do is to make it as visible as possible so
we can avoid it whenever possible.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/