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 > >> 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
Attachment:
Screenshot from 2024-03-26 14-12-50.png
Description: Screenshot from 2024-03-26 14-12-50.png
