Cc: H. Peter Anvin <hpa@...>, Bodo Eggert <7eggert@...>, Christer Weinigel <christer@...>, Ingo Molnar <mingo@...>, Alan Cox <alan@...>, Paul Rolland <rol@...>, Pavel Machek <pavel@...>, Thomas Gleixner <tglx@...>, <linux-kernel@...>, Ingo Molnar <mingo@...>, <rol@...>
On another topic. I have indeed determined what device uses port 80 on
Quanta AMD64 laptops from HP.
I had lunch with Jim Gettys of OLPC a week ago; he's an old friend since
he worked on the original X windows system. After telling him my story
about port 80, he mentioned that the OLPC XO machine had some issues
with port 80 which was by design handled by the ENE KBC device on its
motherboard. He said the ENE was a very desirable chipset for AMD
designs recommended by Quanta. Richard Smith of OLPC explained to me
how the KB3700 they use works, and that they use the KB3700 to send POST
codes out over a serial link during boot up.
This gave me a reason to take apart my laptop, to discover that it has
an ENE KB3920 B0 as its EC and KBC. The port interface for the KB3920
includes listening to port 80 which is then made available to firmware
on the EC. It is recognized and decoded on the LPC bus, only for
writes, and optionally can generate an interrupt in the 8051.
Dumping both the ENE chip, and looking at the DSDT.dsl for my machine, I
discovered that port 80 is used as an additional parameter for various
DSDT methods that communicate to the EC, when it is operating in ACPI mode.
More work is in progress as I play around with this. But the key thing
is that ACPI and perhaps SMM both use port 80 as part of the base
function of the chipset.
And actually, if I had looked at the /sys/bus/pnp definitions, rather
than /proc/ioports, I would have noticed that port 80 was part of a
PNP0C02 resource set. That means exactly one thing: ACPI says that
port 80 is NOT free to be used, for delays or anything else.
This should make no difference here: it's just one more reason to stop
using port 80 for delays on modern machines.
--
