Re: [PATCH 0/5] x86: Cleanups around slow_down_io()

[David Laight <david.laight.linux@gmail.com>]

On Tue, 16 Dec 2025 07:32:09 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On December 16, 2025 5:55:54 AM PST, "Jürgen Groß" <jgross@suse.com> wrote:
> >On 16.12.25 14:48, Ingo Molnar wrote:  
> >> 
> >> * Jürgen Groß <jgross@suse.com> wrote:
> >>   
> >>>> CPUs anymore. Should it cause any regressions, it's easy to bisect to.
> >>>> There's been enough changes around all these facilities that the
> >>>> original timings are probably way off already, so we've just been
> >>>> cargo-cult porting these to newer kernels essentially.  
> >>> 
> >>> Fine with me.
> >>> 
> >>> Which path to removal of io_delay would you (and others) prefer?
> >>> 
> >>> 1. Ripping it out immediately.  
> >> 
> >> I'd just rip it out immediately, and see who complains. :-)  
> >
> >I figured this might be a little bit too evil. :-)
> >
> >I've just sent V2 defaulting to have no delay, so anyone hit by that
> >can still fix it by applying the "io_delay" boot parameter.
> >
> >I'll do the ripping out for kernel 6.21 (or whatever it will be called).
> >
> >
> >Juergen  
> 
> Ok, I'm going to veto ripping it out from the real-mode init code,
> because I actually know why it is there :) ...

Pray tell.
One thing I can think of is the delay allows time for a level-sensitive
IRQ line to de-assert before an ISR exits.
Or, maybe more obscure, to avoid back to back accesses to some register
breaking the 'inter-cycle recovery time' for the device.
That was a good way to 'break' the Zilog SCC and the 8259 interrupt
controller (eg on any reference board with a '286 cpu).

	David

> and that code is pre-UEFI legacy these days anyway.
> 
> Other places... I don't care :)
>