Message-ID: <47862E92.8010003@reed.com>
Date:	Thu, 10 Jan 2008 09:41:22 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Rene Herman <rene.herman@...access.nl>
CC:	Robert Hancock <hancockr@...w.ca>,
	Christer Weinigel <christer@...nigel.se>,
	Zachary Amsden <zach@...are.com>,
	Avi Kivity <avi@...amnet.com>,
	Ondrej Zary <linux@...nbow-software.org>,
	"H. Peter Anvin" <hpa@...or.com>, Bodo Eggert <7eggert@....de>,
	Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Paul Rolland <rol@...917.net>, Pavel Machek <pavel@....cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	rol <rol@...be.net>
Subject: Re: Re: [PATCH] x86: provide a DMI based port 0x80
 I/O delay override.


Rene Herman wrote:
> On 10-01-08 01:37, Robert Hancock wrote:
>>
>> I agree. In this case the BIOS on these laptops is trying to tell us 
>> "port 80 is used for our purposes, do not touch it". We should be 
>> listening.
>
> Listening is fine but what are you going to do after you have 
> listened? Right, not use port 0x80 but since that's the current idea 
> anyway outside of legacy drivers, you don't actually need to listen.
>
> If the quirk-to-0xed or similar was to stay, it's a much better 
> switching point than DMI strings but if not, it's not actually important.
Well, I was just suggesting a warning that would come up when a driver 
that still used port 80 was initialized...
I think that is what Alan Cox and others suggest for legacy drivers that 
have worked - I agree that it may not be the right thing to screw them 
up, especially since my laptop, and probably most machines that might 
start using port 80 or other "legacy ports" won't ever need those drivers.

I thought more about a complete solution last night.   A clean idea that 
really fits the linux design might be the following outline of a patch. 
I suspect it might seem far less ugly, and probably would meet Alan 
Cox's needs, too - I am very sympathetic about not breaking 8390's, etc.

Define a "motherboard resources" driver that claims all the resources 
defined for PNP0C02 devices during the pnp process.   I think Windoze 
actually does something quite similar.   This would claim port 80.

Define an iodelay driver.  This driver exists largely to claim port 80 
for the iodelay operation  (you could even define an option for other 
ports).  Legacy drivers would be modified to require iodelay.  The 
iodelay driver would set up the iodelay mechanism to do something other 
than the "boot time" default - which could be no delay, or udelay.  It 
would also set a flag that says "_b operations are safe".

Put a WARN_ONCE() in the in/out*_b operations that checks the flag that 
is set by the iodelay driver.  This would only trigger in the case that 
80 or whatever was reserved by some other device driver - such as the 
motherboard resources driver above.  Modern machines won't do that.

Finally, anything that happens before the motherboard resources and 
iodelay drivers are initialized cannot use in*_p or out*_p (whether they 
can be loadable modules rather than built in is a question).  This is a 
very small set, and I believe with the exception of the PIT (8253/4) are 
very safe.

Note that this idea is also compatible with rewriting all drivers to use 
"iodelay()" explicitly instead of _p().  But it doesn't require that.

>
> Rene.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists