[PATCH net 2/3] net: ethernet: ti: icssg_common: set irq_disabled after disabling TX IRQ

[Siddharth Vadapalli]

On 26/02/26 05:39, Jakub Kicinski wrote:
> On Wed, 25 Feb 2026 17:01:31 +0530 Siddharth Vadapalli wrote:
>> 	net_rx_action
>> 		__napi_poll
>> 			NAPI TX Handler
>>
>> It does seem strange that the 'net_rx_action' leads to the NAPI TX Handler.
> 
> For historic reason rx_action runs all NAPI, it's fine.
> 
>> However, it is exactly this path that causes the warning, and it is due to
>> this that we could end up in the following situation:
>>
>>                   CPU0                             CPU1
>>      -----------------------------      -----------------------------
>> 1. TX HARD IRQ Handler entered         NAPI TX Handler is running
>> 2. irq_disabled is set to true         Sees irq_disabled being true
>> 3. Calls disable_irq_nosync()          Calls enable_irq()
>> 4. Enters disable_irq_nosync()         [WARNING: Unbalanced enable for IRQ]
> 
> Right, but for Tx NAPI is only scheduled from the IRQ so this is not

But the NAPI TX Handler running on CPU1 at step-1 is a previously queued 
instance and not the one corresponding to the TX HARD IRQ Handler running 
on CPU0 in step-1.

> possible. For Rx yes, AFAICT there are paths in the driver which
> schedule the Rx NAPI (AF_XDP?). But Tx NAPI seemed to have only
> been scheduled by IRQ. And if that's the case the NAPI can't run
> until CPU0's IRQ handler calls napi_schedule().

Wouldn't net_rx_action periodically schedule the NAPI TX Handler? Please 
note the following:
1. The call trace shows net_rx_action scheduling the NAPI TX Handler.
2. Since CPU0 entered the TX HARD IRQ Handler for the TX Completion 
Interrupt, it indicates that the TX Interrupt was indeed enabled at that 
point in time. Hence, a previous instance of the NAPI TX Handler has 
already invoked 'enable_irq()' and enabled the TX Interrupt.
3. Given that 'another' previous instance of the NAPI TX Handler is running 
even though the TX Interrupt is already enabled (given that CPU0 takes the 
interrupt), it indicates that it has been scheduled by some entity.
4. The entity that seems to schedule the NAPI TX Handler despite TX 
Interrupt already being enabled by a previous run of the NAPI TX Handler 
seems to be 'net_rx_action'.