Re: [PATCH] extcon: usbc-tusb320: always rewrite REG9 to deassert INT_N
From: Advait Dhamorikar
Date: Wed Jul 29 2026 - 07:18:48 EST
Hi Alvin,
Thanks for taking a look.
> Can you say a bit more about your hardware?
This is on an NXP i.MX8MP based board using a TUSB320 connected over I²C.
The INT_N signal is connected to a GPIO configured as a level-low interrupt.
I agree that, taken at face value, the datasheet suggests the current
driver logic is correct. However, while debugging this issue I modified
the driver to log both REG9 and the interrupt GPIO level on every interrupt.
On my hardware I consistently observe:
GPIO = 0
REG9 = 0x20
INTERRUPT_STATUS = 0
The handler therefore returns IRQ_NONE, and because the GPIO
interrupt continues to be triggered, the generic IRQ layer eventually reports:
irq 143: nobody cared
Disabling IRQ
This appears inconsistent with my understanding of the datasheet,
which states that INTERRUPT_STATUS should be set whenever
INT_N is asserted. That observation is what initially led me to
investigate rewriting REG9 unconditionally.
> Even though INTERRUPT_STATUS=0 and you're writing 0 to it here?
That motivation came from the datasheet statement that "Rewrites to
this register are needed for the INT_N to be correctly asserted for all
interrupt events." I wanted to determine experimentally whether the
write transaction itself affected the interrupt state, even when
INTERRUPT_STATUS was already clear. This fix, however, appears
to only mask the issue by returning IRQ_HANDLED, preventing the
generic IRQ subsystem from treating the interrupt as unhandled.
The additional logging suggests that returning IRQ_HANDLED in
this path merely masks the issue by preventing the generic IRQ
layer from treating the interrupt as unhandled, rather than addressing
why the interrupt line remains asserted while INTERRUPT_STATUS is clear.
I'm trying to understand why the hardware presents an asserted
INT_N while REG9 reports no pending interrupt.
If there are additional registers or device states useful to inspect
in this situation, I'd be happy to investigate those as well.
Best regards,
Advait