On Tue, 16 Dec 2025 07:32:09 -0800 "H. Peter Anvin" <[email protected]> wrote:
> On December 16, 2025 5:55:54 AM PST, "Jürgen Groß" <[email protected]> wrote: > >On 16.12.25 14:48, Ingo Molnar wrote: > >> > >> * Jürgen Groß <[email protected]> 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 :) >
