Re: [PATCH 1/2] remoteproc: qcom: q6v5_pas: Fix unbalanced handover IRQ enable on attach

[Abel Vesa]

On 26-07-31 10:56:53, Shawn Guo wrote:
> commit bb7c5d6f5b41 ("remoteproc: qcom: q6v5: Make handover IRQ
> one-shot") introduced tracked, idempotent enable/disable helpers for
> the handover IRQ, gated on a new q6v5->handover_irq_enabled flag. It
> converted qcom_q6v5_prepare()/unprepare() and the handover ISR to use
> these helpers, but missed qcom_pas_attach(), which still toggles the
> IRQ directly via enable_irq()/disable_irq() without updating the
> tracked state.
> 
> This desyncs the real IRQ enable depth from handover_irq_enabled for
> any remoteproc that boots up already attached (e.g. ADSP started by
> the bootloader). qcom_pas_attach()'s raw enable_irq() leaves the IRQ
> enabled while handover_irq_enabled stays false, so a subsequent
> stop's qcom_q6v5_unprepare() sees the flag as false and skips
> disabling the IRQ. The next start's qcom_q6v5_prepare() then calls
> enable_irq() on an IRQ that was never disabled, producing:
> 
>   WARNING: Unbalanced enable for IRQ ...
> 
> Additionally, any handover interrupt latched by hardware before probe
> and delivered once qcom_pas_attach() unmasks it is no longer
> suppressed (the ISR's early-return-if-already-issued guard was
> replaced by irq disable-after-first-fire), so it runs the handover
> callback and disables proxy power-domains/clocks that attach() never
> enabled, causing genpd runtime PM usage-count underflow warnings.
> 
> Route qcom_pas_attach()'s IRQ handling through the same
> qcom_q6v5_handover_irq_enable()/qcom_q6v5_handover_irq_disable()
> helpers (now exported) used elsewhere, keeping handover_irq_enabled
> in sync with the real IRQ state.
> 
> Fixes: bb7c5d6f5b41 ("remoteproc: qcom: q6v5: Make handover IRQ one-shot")
> Assisted-by: Claude:claude-sonnet-5
> Signed-off-by: Shawn Guo <shengchao.guo@xxxxxxxxxxxxxxxx>

Thanks for fixing this. I should've caught this on Glymur.

The fix looks sane to me, so:

Reviewed-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>