Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/mediatek: mtk_dsi: IRQ enablement in bind leaves hardware unclocked --
commit 341145986d590feda3b9b8dd572d45aaa3bc1404 Author: AngeloGioacchino Del Regno <[email protected]> drm/mediatek: mtk_dsi: Enable interrupt at component bind time This patch changes the DSI interrupt to be requested with IRQF_NO_AUTOEN during probe, deferring its enablement to the component bind phase. It aims to prevent interrupt storms or premature hardware resets before the display controller is fully bound and ready. > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index 28ba532210ff5..6ac6daa61e684 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] Does enabling the IRQ here leave the hardware vulnerable to unclocked MMIO reads if an interrupt fires before power-on? The hardware clocks (engine_clk, digital_clk) are not enabled until mtk_dsi_poweron() is called. If an interrupt fires immediately after this enable_irq() call, or during any power-off state where mtk_dsi_poweroff() has been called (since disable_irq() is only in mtk_dsi_unbind()), the interrupt handler mtk_dsi_irq() will execute: mtk_dsi_irq() { ... status = readl(dsi->regs + DSI_INTSTA) & flag; ... } On MediaTek SoCs, reading unclocked APB/AHB registers like DSI_INTSTA can cause a bus hang resulting in a synchronous external abort (kernel panic). Could this happen consistently if the bootloader asserts the interrupt, or randomly during suspend/DPMS off if a spurious interrupt occurs? > + > return 0; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
