Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] The DSI interrupt is enabled before hardware clocks are turned on, leaving the system vulnerable to a kernel panic or interrupt storm from unclocked register access. -- commit c2f480f41de24a194e9b0ecae5811e54e2bf871e Author: AngeloGioacchino Del Regno <[email protected]> drm/mediatek: mtk_dsi: Enable interrupt at component bind time This commit requests the DSI interrupt with IRQF_NO_AUTOEN to prevent it from firing prematurely during probe. It explicitly enables the interrupt during component bind and disables it during unbind instead. > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index 0b167b4411e59..ef1638e77f00e 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c [ ... ] > @@ -1101,6 +1102,8 @@ static int mtk_dsi_bind(struct device *dev, struct > device *master, void *data) > return ret; > } > > + enable_irq(dsi->irq); > + [Severity: High] This isn't a bug introduced by this patch, but does this leave the system vulnerable to a kernel panic or interrupt storm from unclocked register accesses? By enabling the interrupt here at the GIC level before the hardware clocks are actually enabled in mtk_dsi_poweron(), the mtk_dsi_irq() handler can be invoked while clocks are off. The handler in drivers/gpu/drm/mediatek/mtk_dsi.c unconditionally accesses DSI_INTSTA: mtk_dsi_irq() { ... status = readl(dsi->regs + DSI_INTSTA) & flag; ... } If a spurious interrupt or a delayed bootloader interrupt fires between mtk_dsi_bind() and mtk_dsi_poweron(), or indefinitely after the display is disabled via mtk_dsi_poweroff() (which disables clocks but does not disable the IRQ), the handler will execute while clocks are off. Accessing hardware registers while clocks are disabled can cause a synchronous external abort. > return 0; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
