[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A776AEA.5030302@gmail.com>
Date: Tue, 04 Aug 2009 00:55:38 +0200
From: Jiri Slaby <jirislaby@...il.com>
To: martyn.welch@...anuc.com
CC: Greg K-H <gregkh@...e.de>, linux-kernel@...r.kernel.org,
devel@...uxdriverproject.org
Subject: Re: [patch 4/5] Staging: vme: add Tundra TSI148 VME-PCI Bridge driver
On 08/04/2009 12:50 AM, Jiri Slaby wrote:
> On 08/03/2009 11:01 PM, Greg K-H wrote:
>> + down(&(vme_irq));
>> +
>> + tsi148_bridge->irq[level - 1].callback[statid].func = NULL;
>
> What if the interrupt comes now?
On the second though, actually nothing worse than "Spurilous VME
interrupt" (if some arch doesn't reorder func and priv_data
assignments). It's not that bad, but still worth fixing.
> I think you want to switch this block
> with "Disable IRQ level" one. And take care of PCI posting (if it is not
> enough that INTEO reaches the device by a consequent INTEN read).
>
>> + tsi148_bridge->irq[level - 1].callback[statid].priv_data = NULL;
>> + tsi148_bridge->irq[level - 1].count--;
>> +
>> + /* Disable IRQ level */
>> + if (tsi148_bridge->irq[level - 1].count == 0) {
>> + tmp = ioread32be(tsi148_bridge->base + TSI148_LCSR_INTEO);
>> + tmp &= ~TSI148_LCSR_INTEO_IRQEO[level - 1];
>> + iowrite32be(tmp, tsi148_bridge->base + TSI148_LCSR_INTEO);
>> +
>> + tmp = ioread32be(tsi148_bridge->base + TSI148_LCSR_INTEN);
>> + tmp &= ~TSI148_LCSR_INTEN_IRQEN[level - 1];
>> + iowrite32be(tmp, tsi148_bridge->base + TSI148_LCSR_INTEN);
>> + }
>> +
>> + /* Release semaphore */
>> + up(&(vme_irq));
>> +}
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists