[PATCH net v3 0/2] Resubmitting with cover-letter and threaded patch series.

[PATCH net v3 0/2] Resubmitting with cover-letter and threaded patch series.

[Selvamani Rajagopal via B4 Relay]

According to OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface
specification, MAC-PHY interrupt is "active low, level triggered".
The specification mentions about the conditions in which the IRQ
is asserted and deasserted.

Bug is inadvertently introduced by treating the IRQ in the OA TC6
framework driver and in dt-binding YAML file as edge triggered.

Changes are done in two files
 - OA TC6 framework Ethernet driver
 - YAML file for the vendor that already uses OA TC6 framework.

Maintainer for this driver is already informed and aware of these
changes. Testing for these changes was done in onsemi's setup and
found to be working.

Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
---
Selvamani Rajagopal (2):
      net: ethernet: oa_tc6: Interrupt is active low, level triggered.
      dt-bindings: net: updated interrupt type to be active low, level triggered

 Documentation/devicetree/bindings/net/microchip,lan8650.yaml | 2 +-
 drivers/net/ethernet/oa_tc6.c                                | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: 02896a7fa4cd3ec61d60ba30136841e4f04bdeac
change-id: 20260531-level-trigger-8cb1a83af034

Best regards,
-- 
Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

[PATCH net v3 1/2] net: ethernet: oa_tc6: Interrupt is active low, level triggered.

[Selvamani Rajagopal via B4 Relay]

From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

According OPEN Alliance 10BASET1x MAC-PHY Serial Interface
specification, interrupt is active low, level triggered.

Fixes: 2c6ce5354453 ("net: ethernet: oa_tc6: implement mac-phy interrupt")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
---
 drivers/net/ethernet/oa_tc6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/oa_tc6.c b/drivers/net/ethernet/oa_tc6.c
index 91a906a7918a..667faf155405 100644
--- a/drivers/net/ethernet/oa_tc6.c
+++ b/drivers/net/ethernet/oa_tc6.c
@@ -1323,7 +1323,7 @@ struct oa_tc6 *oa_tc6_init(struct spi_device *spi, struct net_device *netdev)
 	sched_set_fifo(tc6->spi_thread);
 
 	ret = devm_request_irq(&tc6->spi->dev, tc6->spi->irq, oa_tc6_macphy_isr,
-			       IRQF_TRIGGER_FALLING, dev_name(&tc6->spi->dev),
+			       IRQF_TRIGGER_LOW, dev_name(&tc6->spi->dev),
 			       tc6);
 	if (ret) {
 		dev_err(&tc6->spi->dev, "Failed to request macphy isr %d\n",

-- 
2.43.0

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

[Selvamani Rajagopal via B4 Relay]

From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

According to OPEN Alliance 10BASE-T1x MACPHY Serial Interface (TC6)
specification, interrupt type is active low, level triggered interrupt.

Fixes: ac49b950bea9 ("dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
---
 Documentation/devicetree/bindings/net/microchip,lan8650.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
index 61e11d4a07c4..766ff58147ae 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>;
         local-mac-address = [04 05 06 01 02 03];
         spi-max-frequency = <15000000>;
       };

-- 
2.43.0

Re: [PATCH net v3 1/2] net: ethernet: oa_tc6: Interrupt is active low, level triggered.

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] IRQ storm and starvation caused by level-triggered interrupt without IRQF_ONESHOT or manual masking.
--

commit 3908a29ac2b1392995dbf0f4228af86bbddb0261
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

net: ethernet: oa_tc6: Interrupt is active low, level triggered.

According OPEN Alliance 10BASET1x MAC-PHY Serial Interface
specification, interrupt is active low, level triggered.

> diff --git a/drivers/net/ethernet/oa_tc6.c b/drivers/net/ethernet/oa_tc6.c
> index 91a906a7918a2..667faf1554053 100644
> --- a/drivers/net/ethernet/oa_tc6.c
> +++ b/drivers/net/ethernet/oa_tc6.c
> @@ -1323,7 +1323,7 @@ struct oa_tc6 *oa_tc6_init(struct spi_device *spi, struct net_device *netdev)
>  	sched_set_fifo(tc6->spi_thread);
>  
>  	ret = devm_request_irq(&tc6->spi->dev, tc6->spi->irq, oa_tc6_macphy_isr,
> -			       IRQF_TRIGGER_FALLING, dev_name(&tc6->spi->dev),
> +			       IRQF_TRIGGER_LOW, dev_name(&tc6->spi->dev),
>  			       tc6);

[Severity: High]
Does changing this to a level-triggered interrupt cause an IRQ storm?

Looking at the primary hardirq handler:

drivers/net/ethernet/oa_tc6.c:oa_tc6_macphy_isr() {
    ...
    tc6->int_flag = true;
    wake_up_interruptible(&tc6->spi_wq);
    return IRQ_HANDLED;
}

Since the handler returns IRQ_HANDLED without clearing the hardware condition
on the device, the IRQ core will immediately unmask the line. Because the
MAC-PHY is still holding the line low (waiting for the SPI kthread to run and
clear it), the interrupt will instantly re-trigger.

Could this starve the awakened spi_wq kthread and lead to a CPU lockup or the
kernel permanently disabling the interrupt line? Should this use a threaded
IRQ with IRQF_ONESHOT, or explicitly disable the IRQ in the handler until the
kthread completes the SPI transfer?

>  	if (ret) {
>  		dev_err(&tc6->spi->dev, "Failed to request macphy isr %d\n",

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

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

[sashiko-bot]

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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

On Mon, Jun 01, 2026 at 09:07:19AM -0700, Selvamani Rajagopal via B4 Relay wrote:
> From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> 
> According to OPEN Alliance 10BASE-T1x MACPHY Serial Interface (TC6)
> specification, interrupt type is active low, level triggered interrupt.

Have you checked the documentation for this device etc to make sure that
the device actually follows the spec?
Maybe Parthiban can confirm this for us?

Cheers,
Conor.

> 
> Fixes: ac49b950bea9 ("dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY")
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> ---
>  Documentation/devicetree/bindings/net/microchip,lan8650.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> index 61e11d4a07c4..766ff58147ae 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>;
>          local-mac-address = [04 05 06 01 02 03];
>          spi-max-frequency = <15000000>;
>        };
> 
> -- 
> 2.43.0
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Selvamani Rajagopal]

> -----Original Message-----
> Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
> level triggered
> 
> > According to OPEN Alliance 10BASE-T1x MACPHY Serial Interface (TC6)
> > specification, interrupt type is active low, level triggered interrupt.
> 
> Have you checked the documentation for this device etc to make sure that
> the device actually follows the spec?
> Maybe Parthiban can confirm this for us?

Though I coordinated with Parthiban well ahead about this change, He is the one who could confirm. 

To answer your question, I looked at the datasheet. In one occasion, it mentions "once RESET_N is deasserted, device asserts IRQ_N.
When software clears RESETC bit of OA_STATUS0, device deasserts IRQ_N. This gives me an indication that the interrupt is level triggered.

From our side, I checked with our engineer, who is part of the team that put together the specification, Pier, copied in this email, confirmed that it is level triggered.

> 
> Cheers,
> Conor.
> 
> >
> > Fixes: ac49b950bea9 ("dt-bindings: net: add Microchip's LAN865X 10BASE-T1S
> MACPHY")
> > Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> > ---
> >  Documentation/devicetree/bindings/net/microchip,lan8650.yaml | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> > index 61e11d4a07c4..766ff58147ae 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>;
> >          local-mac-address = [04 05 06 01 02 03];
> >          spi-max-frequency = <15000000>;
> >        };
> >
> > --
> > 2.43.0
> >
> >

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

On Tue, Jun 02, 2026 at 05:36:16PM +0000, Selvamani Rajagopal wrote:
> 
> 
> > -----Original Message-----
> > Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
> > level triggered
> > 
> > > According to OPEN Alliance 10BASE-T1x MACPHY Serial Interface (TC6)
> > > specification, interrupt type is active low, level triggered interrupt.
> > 
> > Have you checked the documentation for this device etc to make sure that
> > the device actually follows the spec?
> > Maybe Parthiban can confirm this for us?
> 
> Though I coordinated with Parthiban well ahead about this change, He is the one who could confirm. 

Please.

Dependant on an ack from Parthiban,
Acked-by: Conor Dooley <conor.dooley@microchip.com>

> 
> To answer your question, I looked at the datasheet. In one occasion, it mentions "once RESET_N is deasserted, device asserts IRQ_N.
> When software clears RESETC bit of OA_STATUS0, device deasserts IRQ_N. This gives me an indication that the interrupt is level triggered.
> 
> From our side, I checked with our engineer, who is part of the team that put together the specification, Pier, copied in this email, confirmed that it is level triggered.
> 
> > 
> > Cheers,
> > Conor.
> > 
> > >
> > > Fixes: ac49b950bea9 ("dt-bindings: net: add Microchip's LAN865X 10BASE-T1S
> > MACPHY")
> > > Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> > > ---
> > >  Documentation/devicetree/bindings/net/microchip,lan8650.yaml | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> > b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
> > > index 61e11d4a07c4..766ff58147ae 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>;
> > >          local-mac-address = [04 05 06 01 02 03];
> > >          spi-max-frequency = <15000000>;
> > >        };
> > >
> > > --
> > > 2.43.0
> > >
> > >
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Parthiban.Veerasooran]

Hi Conor & Selvamani,

On 02/06/26 11:06 pm, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> -----Original Message-----
>> Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
>> level triggered
>>
>>> According to OPEN Alliance 10BASE-T1x MACPHY Serial Interface (TC6)
>>> specification, interrupt type is active low, level triggered interrupt.
>>
>> Have you checked the documentation for this device etc to make sure that
>> the device actually follows the spec?
>> Maybe Parthiban can confirm this for us?
> 
> Though I coordinated with Parthiban well ahead about this change, He is the one who could confirm.
> 
> To answer your question, I looked at the datasheet. In one occasion, it mentions "once RESET_N is deasserted, device asserts IRQ_N.
> When software clears RESETC bit of OA_STATUS0, device deasserts IRQ_N. This gives me an indication that the interrupt is level triggered.
> 
>  From our side, I checked with our engineer, who is part of the team that put together the specification, Pier, copied in this email, confirmed that it is level triggered.

Thank you for notifying me.

Yes, Selvamani had approached me in a different email thread to test 
this change. As I informed him in that email thread, unfortunately we 
could not test it immediately as our team tied up with another project. 
Thank you for your understanding. I now have some bandwidth to proceed 
with the testing and will share feedback as soon as possible.

Before that, I would like to give a heads‑up based on our initial 
development experience. I recall that we initially used an active‑low 
level interrupt, but we ran into issues such as random system stalls 
depending on system load. Our testing was done on a Raspberry Pi 4 with 
LAN8650.

The code flow was as follows: whenever there is an interrupt from the 
MAC‑PHY, the ISR is invoked. The ISR wakes up the SPI thread to perform 
the SPI transfer and then returns. The interrupt remains asserted until 
the MAC‑PHY receives a data chunk from the host.

During further investigation, we found that sometimes there is a 
scheduling latency between the SPI thread wake‑up (triggered from the 
ISR) and the actual execution of the SPI thread due to system load. 
During this gap, the interrupt stays asserted for a long time even 
though the ISR has already returned. With an active‑low level‑triggered 
configuration, this causes the Linux IRQ subsystem to repeatedly invoke 
the ISR, resulting in ISR recurrence and eventual system instability.

In this design, whenever there is an interrupt from the MAC‑PHY, there 
is no way to disable the interrupt or prevent further ISR invocations 
before reacting to it. The only way to deassert the interrupt is by 
sending a data header to the MAC‑PHY. This is the primary reason we 
relied on a falling‑edge interrupt, which resolved the ISR recurrence issue.

My two cents: generally, interrupts are disabled or cleared via a 
register read/write in the ISR, the ISR returns, and the remaining work 
is deferred to a separate task or thread. In this case, however, there 
is no such mechanism, and sending a data header is the only way to clear 
the interrupt. Doing this inside the ISR is not feasible since 
spi_sync() will sleep, which is not allowed in ISR context.

One possible alternative could be to use a threaded IRQ handler with 
IRQF_ONESHOT, where the IRQ line is disabled until the handler 
completes, and sleeping is allowed. In that case, we could perform the 
SPI transfer in the threaded handler to send the data header and 
deassert the interrupt, while deferring the remaining work to a separate 
kthread (the current SPI thread). However, I have not yet tried this 
implementation, so I cannot comment on its behavior or effectiveness 
without implementing and testing it.

I may be missing something here and am trying to clarify my 
understanding. I am also curious why this issue reproduces on our system 
but does not appear in Selvamani’s setup with an active‑low level 
interrupt configuration. If possible, could you share details of your 
setup and how the testing is being performed?

Best regards,
Parthiban V
> 
>>
>> Cheers,
>> Conor.
>>
>>>
>>> Fixes: ac49b950bea9 ("dt-bindings: net: add Microchip's LAN865X 10BASE-T1S
>> MACPHY")
>>> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
>>> ---
>>>   Documentation/devicetree/bindings/net/microchip,lan8650.yaml | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
>> b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
>>> index 61e11d4a07c4..766ff58147ae 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>;
>>>           local-mac-address = [04 05 06 01 02 03];
>>>           spi-max-frequency = <15000000>;
>>>         };
>>>
>>> --
>>> 2.43.0
>>>
>>>
> 

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

[Nicolai Buchwitz]

Hi Parthiban

On 4.6.2026 08:29, Parthiban.Veerasooran@microchip.com wrote:

> [...]

> One possible alternative could be to use a threaded IRQ handler with
> IRQF_ONESHOT, where the IRQ line is disabled until the handler
> completes, and sleeping is allowed. In that case, we could perform the
> SPI transfer in the threaded handler to send the data header and
> deassert the interrupt, while deferring the remaining work to a 
> separate
> kthread (the current SPI thread). However, I have not yet tried this
> implementation, so I cannot comment on its behavior or effectiveness
> without implementing and testing it.

AFAIK both ks8851 and adin1110 request the IRQ as IRQF_TRIGGER_LOW | 
IRQF_ONESHOT
with a NULL primary handler and do everything in the threaded handler. 
SO
looking at these two drivers might be worth the inspiration.


> [...]

REgards
Nicolai