Re: [PATCH] let setup_irq reenable a shared irq

["Uwe Kleine-König" <Uwe.Kleine-Koenig@digi.com>]

Hello,

Thomas Gleixner wrote:
> On Mon, 28 Apr 2008, Uwe Kleine-König wrote:
> > Consider two devices A and B sharing an irq and B already asserts the irq on
> > a booting machine.
> > If the driver for A is loaded first the irq starts triggering and gets
> > disabled after some time by note_interrupt().  Later when the driver for B
> > is loaded the interrupt should be reenabled---other wise both A and B don't
> > work properly.
> 
> Oh no. There is lots of code in drivers, which does:
> 
>    disable_irq();
>    do_some_protected_stuff();
>    enable_irq();
> 
> So when the second driver is loaded on another CPU it would see the
> IRQ_DISABLED bit set and unconditionally reenable the interrupt. 
> 
> This unprotects the protected operation and definitely triggers the
> WARN_ON() in enable_irq() where we check for desc->depth == 0.
mmpf.

It's not nice to use disable_irq()/enable_irq() in a driver, is it?
 
> I can see the rationale for your patch, as we have no way to silence
> stupid hardware or hardware which was left in that state by the BIOS
> other than disabling the interrupt line completely.
> 
> Waht kind of scenario/devices do you have which trigger this ?
It's a ns9215 SoC.  The rtc component has a clock flag that I need to
set before accessing the address space.  After enabling the clock flag
I get an irq if the rtc is up.  The rtc itself uses the same irq.  As I
want to handle the clk enabling in platform code and the actual rtc in a
driver I need a shared irq.
Now the problem is that the rtc remembers its alarm flags over
reboots[1] and starts asserting the irq when the platform code has
requested the irq.

I currently see two ways to handle that:
 1) find an alternative patch similar to the one I sent that don't break
    driver code; or
 2) let the platform code disable the rtc's irqs.

for 1) you need to remember the reason for disabling the irq (or fix all
drivers not to use disable_irq()).  And 2) is ugly because I have to
ioremap then.

Best regards
Uwe

[1] not entirely sure, but I had the rtc in a state in which the rtc
component asserted an irq directly after a reset.

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962