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]

Message-ID: <4790AB82.1010404@davidnewall.com>
Date:	Sat, 19 Jan 2008 00:07:06 +1030
From:	David Newall <davidn@...idnewall.com>
To:	Rene Herman <rene.herman@...access.nl>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David P. Reed" <dpreed@...d.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Zachary Amsden <zach@...are.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Christer Weinigel <christer@...nigel.se>,
	Ondrej Zary <linux@...nbow-software.org>,
	Bodo Eggert <7eggert@....de>, 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 <rol@...be.net>
Subject: Re: Re: [PATCH] x86: provide a DMI based port 0x80
 I/O delay override.

Rene,

Here is why you shouldn't leap so quickly to rudeness.  Everything is
being repeated over and over and over again (as you put it) because
people like you shout down people like me without making any apparent
effort to understand the truth of the problem.


Rene Herman wrote:
> We've already talked about ISA bus speed, and how it's not in a sane
> sense portably determinable, we've already talked about kernel
> parameters, about udelay and it's usefulness in early boot, about how
> your rude "Junk I/O" is exactly what is needed for some ISA devices
> and so on...

The problem is that _p is widely used for non-ISA devices.  For example,
a quick grep reveals the following (and more) all use outb_p:

    ./i2c/busses/i2c-amd756.c
    ./i2c/busses/i2c-ali1535.c
    ./i2c/busses/i2c-ali15x3.c
    ./i2c/busses/i2c-i801.c
    ./i2c/busses/i2c-piix4.c
    ./i2c/busses/i2c-viapro.c
    ./i2c/busses/i2c-nforce2.c
    ./i2c/busses/i2c-ali1563.c
    ./telephony/ixj.c
    ./char/pc8736x_gpio.c
    ./char/epca.c
    ./char/dtlk.c
    ./char/watchdog/w83697hf_wdt.c
    ./char/watchdog/wafer5823wdt.c
    ./char/watchdog/wdt.c
    ./char/watchdog/sc1200wdt.c
    ./char/watchdog/pc87413_wdt.c
    ./char/watchdog/wdt_pci.c
    ./char/watchdog/w83977f_wdt.c
    ./char/watchdog/pcwd_pci.c
    ./char/watchdog/w83877f_wdt.c
    ./char/watchdog/mixcomwd.c
    ./char/watchdog/w83627hf_wdt.c
    ./char/watchdog/advantechwdt.c
    ./char/watchdog/ib700wdt.c
    ./char/watchdog/pcwd.c
    ./char/watchdog/wdt977.c
    ./char/rocket_int.h
    ./char/sonypi.c


Most of these go nowhere near the ISA bus.  This has been said before,
but perhaps you missed that.  Which is another reason to use good
manners, isn't it?

The argument that you can't know how long to delay is utter rubbish.

> In fact, we're blue in the face from talking about it. So say
> something useful or go away. 

I think I'm saying something useful.  I'll keep an eye out for your
humble apology.  (Are you big enough to give one?)   In the mean time,
perhaps you'll follow your own advice and say something useful or go
away.  :-p

I hope you'll see this in the positive and constructive light that it is
intended.
--
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/