Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform

[Arnd Bergmann]

On Thu, Feb 18, 2021 at 1:30 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> The reason drivers/ide is doing that may be related to IDE hard drive
> quirks.  The old WD Caviar drives didn't obey disabling the IDE interrupt
> at the drive level.  On PC, that worked fine, as IRQs 14 and 15 weren't
> shared with other devices.  On systems with shared interrupts, that
> broke badly, and led to an interrupt storm.

So presumably anyone that has one of those old drives will not be
able to move to drivers/ata then? I see that drivers/ata doesn't do
the transfers in interrupt mode, so it would seem to rely on masking
at the device level.

On the other hand, out of the five m68k specific IDE drivers
(gayle, buddha, falcon, mac_ide, q40), only the last two don't
seem to have an ata driver equivalent.

mac_ide uses the highest priority interrupts (NUBUS_C, NUBUS_F)
so it appears to not actually benefit from the nested hardirq but would
benefit being converted to a sata driver with processing at softirq time.

q40 in turn doesn't appear to share interrupts, though its irq_disable()
function probably doesn't do what it should. I could not figure out at
what priority this one runs, and if it is expected to get interrupted.

      Arnd