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

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> So even if that "port 80" access will also cause PCI postings to be 
> flushed, so would the actual IO access that accompanies it, so I don't 
> think that is a very strong argument.
> 
> With all that said: it is certainly possible that the 1us timing makes 
> a difference on some machine, and it is certainly *also* theoretically 
> possible that there is a buggy chipset that posts too much, and the 
> port 80 access might make a difference, but it's not all that likely, 
> and I suspect we'd be better off handling those devices/drivers on a 
> one-by-one basis as we find them.

yeah, wholeheartedly agreed, and this is what x86.git is heading 
towards. All test feedback so far is positive. With strong tools like 
bisection there's no reason why we couldnt approach it this way. If this 
change breaks anything, it will be bisected down to the patch below. In 
fact even io_delay=udelay would be wrong because any problem will be 
less clearly triggerable and thus less bisectable/debuggable.

	Ingo

----------------------->
Subject: x86: make io_delay=none the default
From: Ingo Molnar <mingo@xxxxxxx>

make io_delay=none the default. This is the first step towards removing 
all the legacy io-delay API uses.

Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
---
 arch/x86/Kconfig.debug |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-x86.q/arch/x86/Kconfig.debug
===================================================================
--- linux-x86.q.orig/arch/x86/Kconfig.debug
+++ linux-x86.q/arch/x86/Kconfig.debug
@@ -133,7 +133,7 @@ config IO_DELAY_TYPE_NONE
 
 choice
 	prompt "IO delay type"
-	default IO_DELAY_0X80
+	default IO_DELAY_NONE
 
 config IO_DELAY_0X80
 	bool "port 0x80 based port-IO delay [recommended]"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/