Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

David P. Reed
2007-12-08T19:25:25Z

Alan Cox wrote:
>
> 0x80 should be fine for anything PC compatible anyway, its specifically
> reserved as a debug port and supported for *exactly* that purpose by
> many chipsets.
>
>
Disagree. The definitions of PC compatible are quite problematic. I
have the advantage over some of you young guys, in that I actually wrote
code on one of the first 5 breadboard IBM PCs on the planet at Software
Arts, Inc. and I was directly involved in hardware spec projects with
the original IBM and Compaq engineers. No one actually defined the port
numbered 80h as a "standard" for anything. You won't find it documented
in any early manual for an IBM machine.

The ISA bus supported unterminated transactions safely. That allowed
some clever folks to design BIOS diagnostic tools that optionally
plugged into the bus.

In any case, my machine does not have an ISA bus. Why should it? It's
a laptop!

Now the interesting thing is that I have been scanning the source code
of Linux, and I find gazillions of inb_p outb_p and so forth
instructions where they have NO value. It's as if some hacker who half
understood hardware threw in the _p "just to be safe". Well, it's
neither safe, nor is it economical of code or data. It hangs up the bus
on an MP machine, for example, even when it works, to do the delay by
"outb al,80h"

Worse, the actual requirements of the gazillions of inb_p instructions
for delays are not documented in the code! This is interesting, because
the number of devices likely to need a delay after providing data on an
"in" instruction is very likely to be near zero. After all, the device
has already serviced the bus and delivered data! Why put many
microseconds into the bus, locking out other ISA transactions (and PCI
maybe too) with an out to port 80?

Some of the code in linux is really nice, really clean, really
well-thought out. Some is ... well, I'm not trolling for a fight.