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

["David P. Reed" <dpreed@reed.com>]

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.



--
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/