Re: [RFC] disable_irq()/enable_irq() semantics and ide-probe.c

[Jeff Garzik <jgarzik@pobox.com>]

Benjamin Herrenschmidt wrote:
> On Thu, 2003-10-09 at 18:38, Jeff Garzik wrote:
> 
>>Manfred Spraul wrote:
>>
>>>I'd like to use that for nic shutdown for natsemi:
>>>
>>>   disable_irq();
>>>   shutdown_nic();
>>>   free_irq();
>>>   enable_irq();
>>
>>
>>Why not just shutdown the NIC inside spin_lock_irqsave or disable_irq, 
>>and then free_irq separately?
>>
>>If you can't stop the NIC hardware from generating interrupts, that's a 
>>driver bug.  And if the driver cannot handle its interrupt handler 
>>between the spin_unlock_irqrestore() and free_irq() (shared irq case), 
>>it's also buggy.
> 
> 
> Actually you may still get a stale irq ;) The problem is that IRQs are
> typically an asynchronous event, and an irq can be sort of "queued" up
> (especially if it's a level one) in the PIC... though at least this
> won't be a stale level irq so you won't deadlock in an irq handler that
> can do nothing...

Easily solved with a synchronize_irq()  ;-)

As a slight tangent, with MSI coming up, as well as the presence of 
hardware that queues IRQ events asynchronously, we'll want 
synchronize_irq() to handle those cases, even for uniprocess (often 
synchronize_irq is only defined for SMP).


> Anyway, I quite like the idea. I've been trying to avoid taking a lock
> in some similar shutdown routine for sungem, because some bits in there
> need a few ms delay to workaround a chip bug (or machine sleep will
> break) and I want to schedule. Breaking the lock makes things ugly,
> beeing able to just disable_irq before/after is nice.
> 
> The problem of course is when that irq is shared... you are suddently
> shutting off for a potentially long time a neighbour irq, bad bad...
> (at least I know that on pmac, sungem irq is never shared).

You want to disable_irq() then sleep?  ewww...  :)  I think we could 
figure out a better way...

	Jeff