[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf1cfa86-a12f-437b-a122-8c58ccb01d5f@microchip.com>
Date: Tue, 26 Mar 2024 09:43:33 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <andrew@...n.ch>
CC: <benjamin@...ler.one>, <netdev@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <Horatiu.Vultur@...rochip.com>,
<Woojung.Huh@...rochip.com>, <Nicolas.Ferre@...rochip.com>,
<UNGLinuxDriver@...rochip.com>, <Thorsten.Kummermehr@...rochip.com>,
<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
<pabeni@...hat.com>, <robh+dt@...nel.org>,
<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>, <corbet@....net>,
<Steen.Hegelund@...rochip.com>, <rdunlap@...radead.org>, <horms@...nel.org>,
<casper.casan@...il.com>
Subject: Re: [PATCH net-next v2 0/9] Add support for OPEN Alliance 10BASE-T1x
MACPHY Serial Interface
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
Download attachment "Screenshot from 2024-03-26 14-12-50.png" of type "image/png" (140740 bytes)
Powered by blists - more mailing lists