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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages
Quantcast