David P. Reed wrote:
> Christer Weinigel wrote:
>>
>> Did I miss anyting?
>>
>>
> Nothing that seems *crucial* going forward for Linux. The fate of
> "legacy machines" is really important to get right.
>
> I have a small suggestion in mind that might be helpful in the future:
> the "motherboard resources" discovered as PNP0C02 devices in their _CRS
> settings in ACPI during ACPI PnP startup should be reserved (or
> checked), and any drivers that still use port 80 implicitly should
> reserve that port.
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.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On 10-01-08 01:37, Robert Hancock wrote:
> David P. Reed wrote:
>> I have a small suggestion in mind that might be helpful in the future:
>> the "motherboard resources" discovered as PNP0C02 devices in their _CRS
>> settings in ACPI during ACPI PnP startup should be reserved (or
>> checked), and any drivers that still use port 80 implicitly should
>> reserve that port.
>
> 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.
Rene.
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.
>