Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low, level triggered

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The driver incorrectly handles a level-triggered interrupt without using threaded IRQs or masking the interrupt, which will cause an infinite interrupt storm.
- [High] The custom SPI kthread is stopped before the interrupt handler is disabled, leading to a guaranteed interrupt storm if an interrupt is asserted during module removal.
--

commit 7ca880f8acfa2e8b17a55026e4eceb0ac7d436f9
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

dt-bindings: net: updated interrupt type to be active low, level triggered

This commit updates the lan8650 device tree binding interrupt type to
active low, level triggered, to match the TC6 specification.

> diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> index 61e11d4a07c40..766ff58147ae3 100644
> --- a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> +++ b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> @@ -67,7 +67,7 @@ examples:
>          pinctrl-names = "default";
>          pinctrl-0 = <&eth0_pins>;
>          interrupt-parent = <&gpio>;
> -        interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
> +        interrupts = <6 IRQ_TYPE_LEVEL_LOW>;

[Severity: High]
This is a pre-existing issue, but updating the device tree to use a
level-triggered interrupt exposes a problem in the oa_tc6 driver's interrupt
handling.

The driver explicitly requests a hard-IRQ for a level-triggered interrupt
without IRQF_ONESHOT:

drivers/net/ethernet/oa_tc6.c:oa_tc6_init() {
    ...
    ret = devm_request_irq(&tc6->spi->dev, tc6->spi->irq, oa_tc6_macphy_isr,
                           IRQF_TRIGGER_LOW, dev_name(&tc6->spi->dev),
                           tc6);
    ...
}

The hard-IRQ handler returns IRQ_HANDLED without masking the interrupt or
clearing the hardware state:

drivers/net/ethernet/oa_tc6.c:oa_tc6_macphy_isr() {
    ...
    tc6->int_flag = true;
    /* Wake spi kthread to perform spi transfer */
    wake_up_interruptible(&tc6->spi_wq);

    return IRQ_HANDLED;
}

Since the interrupt is active-low and level-triggered, won't returning
IRQ_HANDLED without masking it or clearing it over SPI immediately trigger
an interrupt storm? Does the driver need to use request_threaded_irq() with
IRQF_ONESHOT to keep the interrupt masked until the thread can clear it?

[Severity: High]
This is also a pre-existing issue, but relying on a level-triggered
interrupt exposes a teardown race condition during module removal.

The driver delegates kthread shutdown to oa_tc6_exit(), stopping the SPI
kthread without explicitly disabling the devm-managed interrupt first:

drivers/net/ethernet/microchip/lan865x/lan865x.c:lan865x_remove() {
    ...
    oa_tc6_exit(priv->tc6);
    free_netdev(priv->netdev);
}

drivers/net/ethernet/oa_tc6.c:oa_tc6_exit() {
    ...
    oa_tc6_phy_exit(tc6);
    kthread_stop(tc6->spi_thread);
}

If the MAC-PHY asserts a level-triggered interrupt after the kthread is
stopped, the hard-IRQ handler will run, call wake_up_interruptible() on the
dead kthread's waitqueue, and return IRQ_HANDLED.

Because the kthread is dead and cannot clear the interrupt, and the ISR does
not mask it, could this result in an unrecoverable system lockup during
driver removal?

>          local-mac-address = [04 05 06 01 02 03];
>          spi-max-frequency = <15000000>;
>        };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601-level-trigger-v3-0-da73e7010532@onsemi.com?part=2