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@xxxxxxxxxx>
>>> ---
>>>   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
>>>
>>>
>