Received-SPF: pass (google.com: domain of linux-kernel+bounces-112656-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Received-SPF: pass (mx2fc6: connection is authenticated)
Message-ID: <ea86159bb555336ae21311770e3a1a6374092e64.camel@bigler.one>
Subject: Re: [PATCH net-next v2 0/9] Add support for OPEN Alliance
 10BASE-T1x MACPHY Serial Interface
From: Benjamin Bigler <benjamin@bigler.one>
To: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
 horatiu.vultur@microchip.com, Woojung.Huh@microchip.com,
 Nicolas.Ferre@microchip.com, UNGLinuxDriver@microchip.com,
 Thorsten.Kummermehr@microchip.com, davem@davemloft.net,
 edumazet@google.com,  kuba@kernel.org, pabeni@redhat.com,
 robh+dt@kernel.org,  krzysztof.kozlowski+dt@linaro.org,
 conor+dt@kernel.org, corbet@lwn.net,  steen.hegelund@microchip.com,
 rdunlap@infradead.org, horms@kernel.org,  casper.casan@gmail.com,
 andrew@lunn.ch
Date: Sun, 24 Mar 2024 12:55:34 +0100
In-Reply-To: <20231023154649.45931-1-Parthiban.Veerasooran@microchip.com>
References: <20231023154649.45931-1-Parthiban.Veerasooran@microchip.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.0
Precedence: bulk
MIME-Version: 1.0

Hi Parthiban

I hope I send this in the right context as it is not related to just one pa=
tch or
some specific code.

I conducted UDP load testing using three i.MX8MM boards in conjunction with=
 the
LAN8651. The setup involved one board functioning as a server, which is jus=
t
echoing back received data, while the remaining two boards acted as clients=
,
sending UDP packets of different sizes in various bursts to the server.
Due to hardware constraints, the SPI bus speed was limited to 15 MHz, which=
 might
have influenced the results.

During the tests I experienced some issues:

- The boards just start receiving after first sending something (ping anoth=
er board).
  Some measurements showed that the irq stays asserted after init. This mak=
es sense
  as far as I understand the chapter 7.7 of the specification, the irq is d=
easserted
  on reception of the first data header following CSn being asserted. As a =
workaround
  I trigger the thread at the end of oa_tc6_init.

- If there is a lot of traffic, the receive buffer overflow error spams the=
 log.

- If there is a lot of traffic, I got various kernel panics in oa_tc6_updat=
e_rx_skb.
  Mostly because more data to rx_skb is added than allocated and sometimes =
because
  rx_skb is null in oa_tc6_update_rx_skb or oa_tc6_prcs_rx_frame_end. Some =
debugging
  with a logic analyzer showed that the chip is not behave correctly. There=
 is more
  bytes between start_valid and end_valid than there should be. Also there
  seems to be 2 end_valid without a start_valid between. What is common is =
that the incorrect
  frame starts in a chunk where end_valid and start_valid is set.
  In my opinion its a problem in the chip (maybe related to the errata in t=
he next point)
  but the driver should be resilent and just drop the packet and not cause =
a kernel panic.

- Sometimes the chip stops working. It always asserts the irq but there is =
no data (rca=3D0)
  and also exst is not active. I found out that there is an errata (DS80001=
075) point s3
  that explains this. I set the ZARFE bit in CONFIG0. This also fixes the p=
oint above.
  The driver now works since about 2.5 weeks with various load with just on=
e loss of frame
  error where I had to reboot the system after about 4 days.

Is there a reason why you removed the netdev watchdog which was active in v=
2?

Thanks,
Benjamin Bigler