On Wed, 2015-12-16 at 06:37AM -0800, Peter Hurley wrote:

On 12/16/2015 01:03 AM, S?ren Brinkmann wrote:

quoted

On Tue, 2015-12-15 at 03:26PM -0800, Peter Hurley wrote:

quoted

On 12/15/2015 07:41 AM, S?ren Brinkmann wrote:

quoted

On Thu, 2015-12-10 at 01:41PM -0800, Peter Hurley wrote:

quoted

On 12/05/2015 08:39 PM, Soren Brinkmann wrote:

quoted

Request_irq() should be _after_ h/w programming, otherwise an
interrupt could be triggered and in-progress before the h/w has been
setup.

Slight misunderstanding. My fault; I should have been more explicit.

1. Any setup necessary for the isr not to be confused and misdirect spurious
   interrupts (or hang) should be before installing the isr with request_irq()
   None of this code should trigger an interrupt.
2. Clear pending interrupts
3. Install the isr with request_irq()
4. Enable interrupts

Isn't that what the startup function is doing now - more or less. I
think 3 and 4 are swapped to release the lock and then do the
request_irq, but I believe that should be OK.
The startup function configures the HW. Clears the ISR. Enables the
intended IRQs and then does the request_irq call.

If the driver enables interrupts before installing the isr with request_irq()
and an interrupt occurs there will the no handler to catch it and EOI the
device.

Really? Shouldn't the IRQ be masked in the interrupt controller until
everything is in place?

Sorry, I'm used to shared interrupts, where that isn't the case.

Ahh, I didn't have to deal with such cases yet. Makes sense though.

	Thanks,
	S?ren