void unexpected_intr (int irq, ide_hwgroup_t * hwgroup);
There's nothing really useful we can do with an unexpected interrupt, other than reading the status register (to clear it), and logging it. There should be no way that an irq can happen before we're ready for it, so we needn't worry much about losing an ``important'' interrupt here.
On laptops (and ``green'' PCs), an unexpected interrupt occurs whenever the drive enters ``idle'', ``standby'', or ``sleep'' mode, so if the status looks ``good'', we just ignore the interrupt completely.
This routine assumes __cli is in effect when called.
If an unexpected interrupt happens on irq15 while we are handling irq14 and if the two interfaces are ``serialized'' (CMD640), then it looks like we could screw up by interfering with a new request being set up for irq15.
In reality, this is a non-issue. The new command is not sent unless the drive is ready to accept one, in which case we know the drive is not trying to interrupt us. And ide_set_handler is always invoked before completing the issuance of any new drive command, so we will not be accidentally invoked as a result of any valid command completion interrupt.
Note that we must walk the entire hwgroup here. We know which hwif is doing the current command, but we don't know which hwif burped mysteriously.