I am using NG6 based custom board with L3.0.35_4.0.0 BSP.
While debugging a kernel panic, related to IPU channel interrupt, triggered early in the kernel initialization, I have discovered a possible race condition that may lead to kernel panic.
Consider the following call chain from drivers/video/mxc/mxc_ipuv3_fb.c:
mxcfb_probe() -> mxcfb_register() -> ipu_request_irq().
The requested interrupt (channel interrupt, EOF) is cleared and then enabled inside ipu_request_irq(). Then immediately after that call there is a call to ipu_disable_irq(mxcfbi->ipu, mxcfbi->ipu_ch_irq).
My understanding (based on the code) is that the intention is to register the interrupt line and to keep it disabled until later time.
However the above sequence is not atomic.
If there is a HW interrupt generated somehow between ipu_request_irq() and ipu_disable_irq() calls, it will be serviced:
__irq_svc() ... mxcfb_irq_handler().
In mxcfb_irq_handler(), there is a completion signalled. However that completion is not initialized, no call to init_completion(&mxc_fbi->flip_complete) yet.
That happens later in _setup_disp_channel2(), in mxcfb_set_par().
Because that completion is not yet initialized, that causes kernel to panic while servicing the EOF interrupt, because some of the completion structure members are not initialized.
I have also looked at imx_3.0.35_4.1.0 and imx_3.0.101 branches, but no code difference in regards to this problem.
Do you think this is a real problem or I have missed something ...