On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote: > On 09-01-08 06:30, Christer Weinigel wrote: > I'd not expect very time crtical. The current outb_p use gives a delay > somewhere between .5 and 2 microseconds as per earlier survey meaning a > udelay(1) or 2 would be enough -- again, at the point that udelay() is > sensible. > > New machines don't use the legacy PIC anymore anyway. > > > The floppy controller code uses outb_p. Even though there might be > > floppy controllers on modern systems, I'd rather leave the floppy code > > alone since it's supposed to be very fragile. If you still use > > floppies you deserve what you get. > > Floppies forever. In practice, leaving it alone isn't going to matter, but > in that same practice changing it to udelay() probably doesn't either. The > ones to leave alone are the ones that are clumsy/impossible to test and the > ones such as in NIC drivers that were specifically tuned.
I'm speaking specifically in terms of 64-bit platforms here. Shouldn't we unconditionally drop outb_p doing extra port I/O on 64-bit architectures? Especially considering they don't even have an ISA bus where the decode timing could even matter? > If simple outb_p() deprecation is considered enough instead, no need to > touch anything in drivers/, only changes to "outb(); udelay()" outside > drivers/. > > I'd let Alan decide here. Agree. Zach -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
