Re: IDE Fixes for PCI, SMP

mlord (mlord@pobox.com)
Wed, 08 Apr 1998 14:17:34 -0400


The IDE drive "cares" about IRQ numbers for the cases where:

1. two or more (non-PCI, or single-FIFO PIC) IDE interfaces
share a single IRQ line.

2. two or more (possibly PCI) IDE interfaces
do NOT share an IRQ line, but nonetheless should never be
active at the same time.

Most of that fuss is for broken chipsets like the CMD640,
as well as for multiple IDE interface boards on a single IRQ.
As of this patch, multiple PCI interface boards are okay without
the fuss.

But.. during work on a Solaris driver this morning, I got distracted
and came up with a much cleaner scheme, that could do away with
the disputed code altogether.

Linus: do you want a fresh patch (discard the current one)
or an incremental patch on top of the current one?

( I will default to the latter ).

Meanwhile, I agree with Linus -- the irq parameter thingie
sounds very broken in the __sparc_v9__ support.
But we probably won't care after my next patch.

-ml

David S. Miller wrote:
>
> Date: Wed, 08 Apr 1998 10:46:48 -0400
> From: mlord <mlord@pobox.com>
>
> + /*
> + * email mlord@pobox.com if broken for __sparc_v9__
> + */
> + spin_lock_irqsave(&hwgroup->spinlock, flags);
> + if (irq == hwif->irq && (handler = hwgroup->handler) != NULL) {
> ide_drive_t *drive = hwgroup->drive;
>
> It is, change this back please..... On sparc_v9 the irq number sent
> to the interrupt handler is not the same thing as the 32-bit interrupt
> cookie you send off to request_irq(). As a consequence the irq
> comparison can never work, this is one of the reasons why the often
> found technique in drivers to have a device array indexed by IRQ
> number was removed by Martin in his PCI cleanups, but it doesn't
> matter on sparc_v9 because we guarentee always that the interrupt
> handler only gets invoked when that exact device is who the interrupt
> is for (ie. you don't get called when an IRQ for another device with
> the same "IRQ number" asserts an interrupt). So for us the test is
> spurious, please put the hack back.
>
> Later,
> David S. Miller
> davem@dm.cobaltmicro.com

-- 
mlord@pobox.com
The Linux IDE guy

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu