* Thomas Gleixner <tglx@xxxxxxxxxxxxx> [170227 08:20]: > On Mon, 27 Feb 2017, Tony Lindgren wrote: > > * Ingo Molnar <mingo@xxxxxxxxxx> [170227 07:44]: > > > Because it's not the requirement that hurts primarily, but the resulting > > > non-determinism and the sporadic crashes. Which can be solved by making the race > > > deterministic via the debug facility. > > > > > > If the IRQ handler crashed the moment it was first written by the driver author > > > we'd never see these problems. > > > > Just in case this is PM related.. Maybe the spurious interrupt is pending > > from earlier? This could be caused by glitches on the lines with runtime PM, > > or a pending interrupt during suspend/resume. In that case IRQ_DISABLE_UNLAZY > > might provide more clues if the problem goes away. > > It's not PM related. That's just silly hardware. At the moment when you > enable some magic bit in the control register, which is required to probe > the version, the fricking thing spits out a spurious interrupt despite the > interrupt enable bit in the same control register being still disabled. Of > course we cannot install an interrupt handler before having probed the > version and setup other stuff, except we add magic 'if (!initialized)' > crappola into the handler and lose the ability to install version dependent > handlers afterwards. OK and presumably no -EPROBE_DEFER happening either. > Wonderful crap that, isn't it? Sounds broken.. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
