On Tue, Feb 11, 2014 at 11:29 AM, Jonas Bonn <jo...@southpole.se> wrote: > Hi Dmitry, > > Seems reasonable. I should obviously apply this and will do so... > > However, I'm a bit curious as to why nobody has reported this earlier. > Are the mor1kx guys running the kernel with the OR1200 option set? Does > mor1kx have the same "bug" WRT clearing interrupts? Have you been > running the mor1kx all this time without ever having been able to mask > interrupts (and things still work???)? Or is there a patch floating > about somewhere that hasn't found its way to me? >
Firstly, as Stefan said, only a fraction of people will use Linux with EDGE trigger, plus not everyone likes warnings. Secondly, the bug exposure also depends on what effect you are supposed to see. If you only have an uart in the system, then it probably won't affect any user experience. Some people will try to use it with ethmac, then, in most cases, uart might just win and then it will look like the ethernet is not working, which may be then somehow resolved without any extra thought. In my case I had a half complete driver which lead to an interrupt lane holding active after rmmod, winning the race on the next modprobe and breaking my uart input. The effect became obvious. This is only explanation I have. There doesn't seem to be any second path which would lead around this bug: handle_level_irq() from kernel/irq/chip.c always calls mask_ack_irq(), which will always call our irq_mask_ack implementation just because we have one. _______________________________________________ Linux mailing list Linux@lists.openrisc.net http://lists.openrisc.net/listinfo/linux
