From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/i915/display: Fix intel_lpe_audio_irq_handler for PREEMPT-RT Date: Thu, 04 Jun 2026 13:25:57 +1000 Message-ID: In-Reply-To: <20260602004515.1907422-1-runyu.xiao@seu.edu.cn> References: <20260602004515.1907422-1-runyu.xiao@seu.edu.cn> <20260602004515.1907422-1-runyu.xiao@seu.edu.cn> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Change:** ```c - ret =3D generic_handle_irq(display->audio.lpe.irq); + ret =3D generic_handle_irq_safe(display->audio.lpe.irq); ``` **Analysis:** - **Correctness:** The fix is correct. `generic_handle_irq()` requires hard= IRQ context (per its documentation: "must be called from an IRQ context wi= th irq regs initialized"). On PREEMPT_RT, the i915 interrupt handler is for= ce-threaded, so it runs in process context. `generic_handle_irq_safe()` exp= licitly handles this by doing `local_irq_save()`/`local_irq_restore()` arou= nd the actual handler dispatch (confirmed at `kernel/irq/irqdesc.c:710-712`= ), making it callable from any context. - **No functional regression on non-RT:** On non-RT kernels where the handl= er already runs in hard IRQ context, interrupts are already disabled, so th= e `local_irq_save()`/`local_irq_restore()` in `generic_handle_irq_safe()` i= s a no-op =E2=80=94 no performance or behavioral difference. - **Scope:** The change is appropriately minimal. Only this one call site i= n `intel_lpe_audio_irq_handler()` needs the fix =E2=80=94 the caller is the= i915 IRQ handler chain, and this is the point where IRQs get forwarded to = the LPE audio chained IRQ chip. - **Commit message:** Accurate and clear. Correctly identifies the PREEMPT_= RT threading issue and the Braswell audio platform affected. **No issues found.**=20 Reviewed-by worthy as-is. --- Generated by Claude Code Patch Reviewer