[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 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

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

[Selvamani Rajagopal]

> Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
> level triggered
> 
> Hi Conor & Selvamani,
> 
[.]
> 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 can test this in my setup.

> 
> 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?

My setup is similar to yours. We have Raspberry Pi boards (P-4 & Pi-5) connected
to our MAC-PHY evaluation board. As you could see in my patch submissions, 
there are no changes to oa_tc6.c in the way interrupts are handled.

> 
> Best regards,
> Parthiban V
> >
> >>
> >> Cheers,
> >> Conor.
> >>
> >>>

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: 1992 bytes --]

On Thu, Jun 04, 2026 at 03:21:47PM +0000, Selvamani Rajagopal wrote:
> > Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
> > level triggered
> > 
> > Hi Conor & Selvamani,

To be clear, my angle here is making sure that the microchip device is
not deviant from the spec. I don't know or care about this hardware in
particular.
I just made the assumption that what was in the example worked, and
wanted clarification that what the example was changed to actually
reflected something else that worked on the hardware in question before
I gave an ack. I'm a dt-binding maintainer, not someone with knowledge
of these devices.

> > 
> [.]
> > 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 can test this in my setup.
> 
> > 
> > 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?
> 
> My setup is similar to yours. We have Raspberry Pi boards (P-4 & Pi-5) connected
> to our MAC-PHY evaluation board. As you could see in my patch submissions, 
> there are no changes to oa_tc6.c in the way interrupts are handled.
> 
> > 
> > Best regards,
> > Parthiban V
> > >
> > >>
> > >> Cheers,
> > >> Conor.
> > >>
> > >>>
> 

[-- 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

[Andrew Lunn]

> I just made the assumption that what was in the example worked, and
> wanted clarification that what the example was changed to actually
> reflected something else that worked on the hardware in question before
> I gave an ack.

That is the problem with edge interrupts when level should be
used. They work %99.9 of the time, so many developers don't notice
they have it wrong. And then one day it all stops because an interrupt
got lost.

    Andrew

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

[Parthiban.Veerasooran]

On 04/06/26 10:30 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> I just made the assumption that what was in the example worked, and
>> wanted clarification that what the example was changed to actually
>> reflected something else that worked on the hardware in question before
>> I gave an ack.
> 
> That is the problem with edge interrupts when level should be
> used. They work %99.9 of the time, so many developers don't notice
> they have it wrong. And then one day it all stops because an interrupt
> got lost.
I agree with this point. But simply changing the interrupt type in the 
existing logic is not sufficient. Level‑triggered interrupts require 
careful handling in the driver, and with the current implementation I am 
observing issues under system load when using level‑triggered IRQs, as 
also discussed in another thread.

Best regards,
Parthiban V
> 
>      Andrew

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

[Selvamani Rajagopal]

> Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
> level triggered
> 
> 
> This Message Is From an External Sender
> This message came from outside your organization.
> 
> On 04/06/26 10:30 pm, Andrew Lunn wrote:
> >
> > That is the problem with edge interrupts when level should be
> > used. They work %99.9 of the time, so many developers don't notice
> > they have it wrong. And then one day it all stops because an interrupt
> > got lost.
> I agree with this point. But simply changing the interrupt type in the
> existing logic is not sufficient. Level‑triggered interrupts require
> careful handling in the driver, and with the current implementation I am
> observing issues under system load when using level‑triggered IRQs, as
> also discussed in another thread.


Parthiban,

I agree. When we change to level triggered interrupt, current mechanism won't work as
we are not disabling the interrupt when we handle them.

I have a modification ready that uses threaded IRQ mechanism, which disables further interrupt until the
thread returns.(with level trigger changes of course).  My simple tests (ping and ptp4l) work fine with those 
changes I am going to run some heavy traffic tests.  If I find them stable, I will post them in my next v3 submission.

> 
> Best regards,
> Parthiban V
> >
> > Andrew

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

[Andrew Lunn]

> I agree. When we change to level triggered interrupt, current mechanism won't work as
> we are not disabling the interrupt when we handle them.

I'm kind of surprised about that. If you only provide a thread context
handler, but not a interrupt context handler, i would of expected the
IRQ core to leave the interrupt disabled until the threaded handler
exited. But maybe it is historic behaviour.

	Andrew

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

[Selvamani Rajagopal]

> Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
> level triggered
> 
> 
> > I agree. When we change to level triggered interrupt, current mechanism won't work as
> > we are not disabling the interrupt when we handle them.
> 
> I'm kind of surprised about that. If you only provide a thread context
> handler, but not a interrupt context handler, i would of expected the
> IRQ core to leave the interrupt disabled until the threaded handler
> exited. But maybe it is historic behaviour.


You are right. I was just highlighting the need for moving to 
threaded IRQ when we move to level triggered interrupt.

As you know, the current code doesn't have threaded IRQ.
It has ISR waking up a thread that handles the interrupt
 
> Andrew

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

[Parthiban.Veerasooran]

Hi Selvamani,

On 08/06/26 10:14 am, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> Subject: Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
>> level triggered
>>
>>
>> This Message Is From an External Sender
>> This message came from outside your organization.
>>
>> On 04/06/26 10:30 pm, Andrew Lunn wrote:
>>>
>>> That is the problem with edge interrupts when level should be
>>> used. They work %99.9 of the time, so many developers don't notice
>>> they have it wrong. And then one day it all stops because an interrupt
>>> got lost.
>> I agree with this point. But simply changing the interrupt type in the
>> existing logic is not sufficient. Level‑triggered interrupts require
>> careful handling in the driver, and with the current implementation I am
>> observing issues under system load when using level‑triggered IRQs, as
>> also discussed in another thread.
> 
> 
> Parthiban,
> 
> I agree. When we change to level triggered interrupt, current mechanism won't work as
> we are not disabling the interrupt when we handle them.
> 
> I have a modification ready that uses threaded IRQ mechanism, which disables further interrupt until the
> thread returns.(with level trigger changes of course).  My simple tests (ping and ptp4l) work fine with those
> changes I am going to run some heavy traffic tests.  If I find them stable, I will post them in my next v3 submission.
Thank you for the update. I have also implemented threaded IRQ handling, 
and it works fine on my side as well. Since you are already planning to 
post patches for this implementation and have mentioned that you will 
include them in your next submission, I will hold off on posting my 
patch for now. Please let me know if you would like me to share it from 
my side.

Best regards,
Parthiban V
> 
>>
>> Best regards,
>> Parthiban V
>>>
>>> Andrew
> 

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

[Paolo Abeni]

On 6/1/26 6:07 PM, Selvamani Rajagopal via B4 Relay wrote:
> 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>

Note for future submissions: the cover letter subj must refer to the
series content, and not to changes from the previous revision.

/P

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

[Selvamani Rajagopal]

> >
> > 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>
> 
> Note for future submissions: the cover letter subj must refer to the
> series content, and not to changes from the previous revision.

Understood. Thanks.

> 
> /P