Hi Andrew,

On 25/03/24 7:31 pm, Andrew Lunn wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

quoted

It looks like the IRQ is asserted on RESET completion and expects a data
chunk from host to deassert the IRQ. I used to test the driver in RPI 4
using iperf3. For some reason I never faced this issue, may be when the
network device is being registered there might be some packet
transmission which leads to deliver a data chunk so that the IRQ is
deasserted.

If you have IPv6 enabled, the network stack will try to add a link
local IPv6 address to the interface, which means performing a
Duplicate Address Detection. That means sending a few packets.

Try disabling IPv6 if you want to reproduce the problem.

Yes, I saw that IPv6 is enabled by default in my RPI 4. So as you 
mentioned, I tried disabling it but still approximately in 1 second 
there is a packet coming from the n/w stack which makes the IRQ 
deasserted (Refer the attached screenshot). So just for testing, I 
disabled waking up the SPI thread from the oa_tc6_start_xmit() function 
and noted that the IRQ is not deasserted throughout the period in Logic 
analyzer.

As I replied in the previous email, using the below code makes the IRQ 
deasserted when the oa_tc6_init() finishes without expecting any data 
chunk from oa_tc6_start_xmit(). So in my opinion let's stick with this 
solution.

/* oa_tc6_sw_reset_macphy() function resets and clears the MAC-PHY reset
  * complete status. IRQ is also asserted on reset completion and it is
  * remain asserted until MAC-PHY receives a data chunk. So performing an
  * empty data chunk transmission will deassert the IRQ. Refer section
  * 7.7 and 9.2.8.8 in the OPEN Alliance specification for more details.
  */
tc6->int_flag = true;
wake_up_interruptible(&tc6->spi_wq);

Best regards,
Parthiban V

           Andrew