[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <475DEB23.1000304@davidnewall.com>
Date: Tue, 11 Dec 2007 12:12:59 +1030
From: David Newall <david@...idnewall.com>
To: "H. Peter Anvin" <hpa@...or.com>
CC: Krzysztof Halasa <khc@...waw.pl>,
Rene Herman <rene.herman@...access.nl>,
Pavel Machek <pavel@....cz>, Andi Kleen <andi@...stfloor.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
"David P. Reed" <dpreed@...d.com>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64
with MCP51 laptops
H. Peter Anvin wrote:
> David Newall wrote:
>> Where did the 8us delay come from? The documentation and source is
>> careful not to say how long the delay is. Would changing it to, say
>> 1us, be technically wrong? Is code that requires 8us correct?
>
> I think a single ISA bus transaction is 1 µs, so two of them back to
> back should be 2 µs, not 8 µs...
Exactly. You think it's 2us, but the documentation doesn't say. The _p
functions are generic inasmuch as they provide an unspecified delay.
Drivers which work across platforms, and which use _p, therefore have
different delays on different platforms. Should the length of the delay
be unimportant? I wouldn't have thought so. If it is important, does
that mean that such drivers are buggy on some platforms?
I really *hate* the idea that access to non-present hardware is used to
generate a delay. That sucks so badly. It's worthy of a school-aged
hacker, not of a world-leading operating system. It's so not
best-practice that it's worst-practice.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists