On December 16, 2025 11:59:12 AM PST, David Laight <[email protected]> wrote: >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 :) >> > >
A20 gate logic on some motherboards, especially.
