Re: [RFC][PATCH] irq: remove IRQF_DISABLED

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Monday 02 March 2009, Linus Torvalds wrote:
> 
> On Mon, 2 Mar 2009, Bartlomiej Zolnierkiewicz wrote:
> > > 
> > > Could we make just the IDE driver itself enable interrupts? Sure. But that 
> > 
> > Actually it has been doing it for years (some host drivers don't do this by
> > default and still need "hdparm -u" or equivalent but I was planning to change
> > it for 2.6.30).
> 
> The IDE layer has the option to enable irq's during the transfer itself, 
> yes.  But it actually works the reverse way from what you think: the irq 

Hmm, I said nothing about how it is implemented in the IDE code itself. :)

> layer will enable interrupts, and the IDE layer will then _not_ disable 
> them during the transfer if you use "hdparm -u".
> 
> Look at ide_intr: it generally gets called with interrupts _enabled_ 
> (because it doesn't use IRQF_DISABLED) and then it does:
> 
>         spin_lock_irqsave(&hwif->lock, flags);
> 	..
>         spin_unlock(&hwif->lock);
> 	..
>         if (drive->dev_flags & IDE_DFLAG_UNMASK)
>                 local_irq_enable_in_hardirq();
> 	...
> 	spin_lock_irq(&hwif->lock);
> 	...
> 	spin_unlock_irqrestore(&hwif->lock, flags);
> 
> where the magic thing is how it enables irqs again if the "irq unmask" 
> flag is set.
> 
> The point I'm making is that 
> 
>  - as far as the generic irq layer is concerned, IDE might as well have 
>    interrupts enabled all the time (and disabling them is a local issue, 
>    more to do with locking and with timing-induced hardware _bugs_ rather 
>    than anything else)
> 
>  - .. and more importantly, that is AS IT MUST BE. Because quite frankly, 
>    if the irq handler enables interrupts (like IDE does), the generic IRQ 
>    layer really _must_ know about it, because it may depend on 
>    non-reentrancy of that interrupt.

Fixing this is on long-term TODO (there was just a ton of more high-prio
stuff to take care of first).

Thanks,
Bart