Re: [PATCH] usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop

> On Aug 20, 2026, at 16:13, Konrad Dybcio <[email protected]> wrote:
> 
> Doesn't this make disable_irq() get called undesirably?
> 
> Konrad

Hi Konrad,

Thanks for pointing this out.

On the port_start() failure path the port IRQs have indeed not been
enabled: they are requested with IRQF_NO_AUTOEN, and the enable_irq()
loop is the last step in port_start(). Routing that path through
port_stop() therefore adds a nested disable_irq() on already-disabled
IRQs. __disable_irq() only acts when the depth goes 0 -> 1, so this
is just a counter bump on that leg — no hardware access, no warning,
and devm frees those IRQs right after on the same unwind. But I agree
it is not an ideal cleanup contract.

The reason I routed it through port_stop() is to make sure
cc_debounce_dwork is disabled and drained before tcpm_unregister_port().
tcpm_register_port() runs before port_start() and may already have
queued the TCPM state machine; that worker can call set_cc() or
start_toggling() and arm the delayed work even when port_start() later
fails.

If you find the extra disable_irq() undesirable I will revise the
cleanup so the failed-start path only disables/drains the delayed work,
leaving port_stop() for the paths where the port was actually started,
and send an updated patch.

Thanks,
Fan