linux-kernel - Re: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Jan 2008 18:51:20 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"David P. Reed" <dpreed@...d.com>
Cc:	Ondrej Zary <linux@...nbow-software.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rene Herman <rene.herman@...access.nl>,
	Bodo Eggert <7eggert@....de>,
	Christer Weinigel <christer@...nigel.se>,
	Ingo Molnar <mingo@...e.hu>, 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@...be.net
Subject: Re: Re: [PATCH] x86: provide a DMI based port 0x80
 I/O delay override.

> There is no need to use io writes to supposedly/theoretically "unused 
> ports" to make drivers work on any bus.

The natsemi docs here say otherwise. I trust them not you.

> don't remember writing a driver for the 3com devices - probably didn't, 
> because 3Com's cards were expensive at the time.

3C503 needs delays for some setups according to the docs. I can't tell
you how the 3COM drivers did it as that was a different bit of 3com to
the bit I worked for. From the rest of 3Com I saw probably utterly
vilely ;)

Later 3Com stuff was either sane (3c509 etc) or used whacko intel chips
(3c507/27) which had their own special breed of insanity to replace
address setup delay bugs.

> In any case, Linux *did* adopt this port 80 strategy - I'm sure all 
> concerned thought it was frightfully clever at the time.  Linus 
> expressed his skepticism in the comments in io.h.  The problem is to 
> safely move away from it toward a proper strategy 

No. The problem is that certain people, unfortunately those who know
nothing about ISA related bus systems, keep trying to confuse ISA delay
logic with core chip logic and end up trying to solve both a problem and a
non-problem in one, creating a nasty mess in the process.

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