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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux