Hey Luis, > Your diagnosis seem to be correct and I have already tried to address > this: > > https://lkml.org/lkml/2012/8/25/84 Oh, w00ps, seems I missed that patch, stupid of me... > I've submitted a patch to try to fix it but got no comments yet. My > patch moves the request_irq() invocation further down the > initialisation code, after the rc_register_device() (which I believe > is the correct thing to do). I applied your patch and ran a diff against my four patches. If I disregard the label changes, there's still three changes between our patches I can see: - You move the rc_register_device calls only above the request_irq call, while I also included the request_region call. I don't think this should cause any realy difference. - You didn't remove the "dev->hw_io = -1" and "dev->irq = -1" lines in ene_ir.c, which I think are no longer needed now there are different multiple cleanup labels. - You did not move up the "...->rdev = rdev" line in fintek-cir.c, nuvoton-cir.c and ite-cir.c, which I think means the bug is not completely solved for these drivers with your patch. As for the last point, I did a test run with your patch and could no longer reproduce the issue (though I'm pretty confident the original really was nvt->rdev being NULL). I suspect this means that moving the rc_register_device() up to before the request_irq, prevents the bug from triggering because either rc_register_device() did something to trigger a (pending) interrupt, or it just took long enough for an interrupt to occur. In either case, I believe there is still a race condition between the first interrupt and the initialization of of nvt->rdev, which could be fixed by also moving the rdev initialization a bit further up. Or am I missing some point here? Gr. Matthijs
Attachment:
signature.asc
Description: Digital signature
