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

["H. Peter Anvin" <hpa@xxxxxxxxx>]

On December 16, 2025 11:59:12 AM PST, David Laight 
<david.laight.linux@xxxxxxxxx> wrote:
>On Tue, 16 Dec 2025 07:32:09 -0800
>"H. Peter Anvin" <hpa@xxxxxxxxx> wrote:
>
>> On December 16, 2025 5:55:54 AM PST, "Jürgen Groß" <jgross@xxxxxxxx> wrote:
>> >On 16.12.25 14:48, Ingo Molnar wrote:  
>> >> 
>> >> * Jürgen Groß <jgross@xxxxxxxx> 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 :)
>> 
>
>

A20 gate logic on some motherboards, especially.