[PATCH 3/4] libata-sff.c: add another IRQ calls

[PATCH 3/4] libata-sff.c: add another IRQ calls

[Akira Iguchi]

When enabling IRQ, ap->ops->irq_on is checked.
Because most drivers can use ata_irq_on() as is, this
patch allows ap->ops->irq_on to be NULL.
If it is NULL, ata_irq_on() are used.

Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: Akira Iguchi <akira2.iguchi@toshiba.co.jp>
---

--- linux-2.6.20-rc4/drivers/ata/libata-sff.c.orig	2007-01-17 01:45:56.000000000 +0900
+++ linux-2.6.20-rc4/drivers/ata/libata-sff.c	2007-01-17 02:16:00.000000000 +0900
@@ -724,8 +724,12 @@ void ata_bmdma_thaw(struct ata_port *ap)
 	/* clear & re-enable interrupts */
 	ata_chk_status(ap);
 	ap->ops->irq_clear(ap);
-	if (ap->ioaddr.ctl_addr)	/* FIXME: hack. create a hook instead */
-		ata_irq_on(ap);
+	if (ap->ioaddr.ctl_addr) {	/* FIXME: hack. create a hook instead */
+		if (ap->ops->irq_on)
+			ap->ops->irq_on(ap);
+		else
+			ata_irq_on(ap);
+	}
 }
 
 /**

Re: [PATCH 3/4] libata-sff.c: add another IRQ calls

[Alan]

On Tue, 16 Jan 2007 19:46:23 +0900
Akira Iguchi <akira2.iguchi@toshiba.co.jp> wrote:

> When enabling IRQ, ap->ops->irq_on is checked.
> Because most drivers can use ata_irq_on() as is, this
> patch allows ap->ops->irq_on to be NULL.
> If it is NULL, ata_irq_on() are used.


I believe you can now remove the if(ap->ioaddr.ctl_addr) check as any
device lacking a ctl_addr can now provide an irq_on() method using your
changes.

You've fixed the FIXME 

Re: [PATCH 3/4] libata-sff.c: add another IRQ calls

[Jeff Garzik]

Alan wrote:
> On Tue, 16 Jan 2007 19:46:23 +0900
> Akira Iguchi <akira2.iguchi@toshiba.co.jp> wrote:
> 
>> When enabling IRQ, ap->ops->irq_on is checked.
>> Because most drivers can use ata_irq_on() as is, this
>> patch allows ap->ops->irq_on to be NULL.
>> If it is NULL, ata_irq_on() are used.
> 
> 
> I believe you can now remove the if(ap->ioaddr.ctl_addr) check as any
> device lacking a ctl_addr can now provide an irq_on() method using your
> changes.
> 
> You've fixed the FIXME 

Agreed.

Abstracting out the Control/Alt-Status register block operations has 
been a long-standing TODO that I knew would be required, sometime down 
the line.  I certainly support adding such abstractions, as they are 
required for several non-x86 IDE drivers, not just Cell.

	Jeff