I didn't mean "can't reasonably mix" as in "it's not reasonably
possible", but as in "it's not reasonably meaningful".
The while idea with "fast" interrupts is that they only exist for things
that need the CPU _now_ and they go away quickly. All other interrupts
are disabled during a fast interrupt, while during a normal interrupt
only the IRQ that resulted in the interrupt is disabled (so that we
don't get recursive interrupts).
Now, the fast interrupts are quicker than normal interrupts: they save
less state on the stack and they also potentially do less IRQ handler
setup (no need to mess with IRQ bitmaps etc to disable ourselves). But
there is no other difference: anything a fast irq does, a slow irq can
do as well (with slightly more overhead).
Now, mixing fast and slow interrupts simply doesn't make sense: the end
result would be equal or more overhead to just the simpler case of
mixing just normal interrupts in the first place.
Moral of the story: "just don't do it, then". If drivers want to share
interrupts, that's fine, but they have to know that if they request a
fast interrupt it can't be shared with a slow one (it's debatable if
it's even a good idea to share two fast interrupts, but at least that
makes some kind of sense).
Linus